Add Arduino-ESP32 3.3.11 compatibility

[LuoIsHere]

Summary

This PR adds support for Arduino-ESP32 3.3.11 while preserving the existing Arduino-ESP32 2.x build environment and runtime behavior.

The update addresses API and driver changes introduced in Arduino-ESP32 3.x, including I2C, hardware timers, LEDC/PWM, USB CDC, ESP-NOW callbacks, and Wi-Fi station MAC retrieval. It also adds CI coverage for both framework generations.

Motivation

When running the original firmware on Arduino-ESP32 3.x, several compatibility problems were observed:

• Mixing the new and legacy ESP-IDF I2C drivers caused a runtime abort.
• VL53LX I2C transfer errors were not propagated to the upper layers, which could leave ToF initialization waiting indefinitely.
• WiFi.macAddress() could return an all-zero address during startup, causing the controller to save an invalid ESP-NOW peer address.
• Timer, LEDC, USB CDC, and ESP-NOW callback APIs have changed between Arduino-ESP32 2.x and 3.x.

Changes

Arduino-ESP32 compatibility

• Added a dedicated PlatformIO environment for Arduino-ESP32 3.3.11.
• Kept the original Arduino-ESP32 2.x environment available for backward compatibility.
• Added shared compatibility macros based on the official Arduino-ESP32 version definitions.
• Added a startup log showing the active Arduino-ESP32 version and compatibility branch.
• Adapted hardware timer APIs for Arduino-ESP32 3.x.
• Adapted motor and buzzer LEDC/PWM APIs while preserving the original channel, frequency, resolution, and motor mapping.
• Adapted ESP-NOW send and receive callback signatures.
• Preserved the existing 2.x implementation through conditional compilation.

ToF and I2C

• Added an Arduino-ESP32 3.x I2C compatibility layer.
• Avoided mixing the new ESP-IDF I2C driver with the legacy command-link driver.
• Added argument, transfer-length, and result validation.
• Increased the I2C transaction timeout to accommodate the actual sensor initialization flow.
• Propagated I2C transfer failures through the VL53LX platform layer instead of reporting false success.
• Added an I2C scan after changing the front ToF address to verify the transition from 0x29 to 0x2A.
• Preserved the existing VL53LX address semantics and the Arduino-ESP32 2.x implementation.

ESP-NOW

• Added esp_mac.h support for Arduino-ESP32 3.x.
• Read the station MAC using esp_read_mac(..., ESP_MAC_WIFI_STA).
• Checked both the API result and whether the returned MAC address is all zero.
• Prevented pairing broadcasts when the local MAC address is invalid, avoiding invalid peer addresses being stored by the controller.
• Kept the original WiFi.macAddress() path for Arduino-ESP32 2.x.

CI and repository cleanup

• Added a PlatformIO build matrix covering:
  • The existing Arduino-ESP32 2.x environment.
  • The new Arduino-ESP32 3.3.11 environment.
• Updated the Arduino Lint workflow to support repositories using either main or master.
• Updated GitHub Actions dependencies and added manual workflow triggers.
• Fixed the duplicated exclude key in the clang-format workflow.
• Restored source and header file permissions from 100755 to 100644.
• Removed unintended CRLF and trailing-whitespace changes from the affected source files.

Backward Compatibility

The existing Arduino-ESP32 2.x environment and implementation paths remain available. Version-specific behavior is isolated through conditional compilation.

This PR does not intentionally change:

• Flight-control algorithms or tuning parameters.
• ESP-NOW packet formats.
• Motor channel or GPIO mappings.
• ToF sensor address semantics.
• Existing Arduino-ESP32 2.x initialization behavior.

Validation

• Hardware tested on M5StampFly.
• Hardware tested on M5StampFly V1.1.
• Verified complete sensor initialization.
• Verified front ToF address reassignment and ToF ranging.
• Verified ESP-NOW pairing and remote-control operation.
• Verified motor/PWM operation and takeoff behavior.
• git diff --check passes.
• GitHub Actions workflow YAML files parse successfully.
• CI is configured to build both Arduino-ESP32 environments.

Notes

The configured I2C timeout is a maximum wait time, not an unconditional delay. Successful transfers return as soon as the underlying transaction completes.