Add BLE CRSF telemetry mode for ESP32C3 TX backpack

[nileshmdev]

Scope

CRSF telemetry only. MAVLink is not forwarded over BLE in this PR.
For MAVLink, continue using the existing WIFI UDP transport.

---

Companion PR

Radio-side UI change that lets the user actually select the new
"Bluetooth" telemetry mode: ExpressLRS/ExpressLRS#3671

Neither PR breaks anything when merged alone:

• This PR (receiver) just adds handling for the new mode value; old
  radios never send it.
• The ExpressLRS PR (sender) just adds a menu option; old backpacks
  silently ignore unknown mode values.

Suggested merge order: this Backpack PR first, then the ExpressLRS
PR. That way no user sees a menu option that does nothing because their
backpack firmware doesn't support it yet.

Summary

Adds an opt-in BLE transport for the ESP32C3 TX backpack so CRSF
telemetry can be viewed on phones / browsers that speak the HM-10 GATT
profile, alongside the existing ESP-NOW and WiFi UDP transports.

Changes

• New BACKPACK_TELEM_MODE_BLUETOOTH mode wired into the existing TLM-mode
  config flow.
• HM-10 telemetry service 0xFFE0 / 0xFFE1 with READ | NOTIFY.
• Standard GATT Device Information Service (0x180A) so the backpack
  identifies itself cleanly to scanners.
• Gated by BLE_TELEM_ENABLED; only enabled for
  ESP32C3_TX_Backpack_via_UART. Other targets unchanged.
• Adds h2zero/NimBLE-Arduino @ ^2.5.0 dependency for that target only.

Drive-by fixes (justified by the BLE work)

• SetSoftMACAddress() is now called before devicesInit() so
  firmwareOptions.uid is populated in time for the BLE device name.
  Because devicesInit() then runs wifiOff(), the call is repeated
  before esp_now_init() to keep ESP-NOW working.

  Overlap with PR TLM WiFi mode fix #219 (TLM WiFi mode fix). That PR also touches
  SetSoftMACAddress() placement. I hit issues with all three
  telemetry modes during local testing and needed this version of the
  fix to get ESPNOW / WIFI / BLE all working together. Happy to rebase
  on TLM WiFi mode fix #219 once it lands, or drop this hunk if maintainers prefer.

• MSP_ELRS_BACKPACK_CRSF_TLM now routes telemetry to exactly one
  transport. Previously WIFI and ESPNOW were sent in parallel (the
  ESP-NOW path silently failed in WIFI mode because ESP-NOW isn't
  initialised there). This also avoids 2.4 GHz radio contention in BLE
  mode.

---

Test plan

All three telemetry modes (WIFI, ESPNOW, BLE) tested end-to-end.

Hardware used

• RadioMaster TX15 Max
• RadioMaster Nomad Xrossband TX

Test app

Used my own viewer: https://nileshmdev.github.io/flighttrace/#/

The web app supports all three transports:

Mode	How to test
WIFI	Install the companion app from the project's release area
ESP-NOW	ESP-NOW-to-USB bridge module (Web Serial)
BLE	Test directly from the web app (Web Bluetooth)

Results

• BLE: device advertises as ELRS Backpack XXXXXX, DIS values readable,
  0xFFE1 notifications carry BE EF heartbeat + live CRSF telemetry.
• ESPNOW: tested via an ESP-NOW-to-USB bridge module — CRSF telemetry
  received and decoded by the web app over USB serial.
• WIFI: QGC / web app receive MAVLink over UDP unchanged from user
  perspective; redundant ESP-NOW path (which was failing silently) is no
  longer attempted.

---

Screenshots

(BLE telemetry viewed in app — screenshot to be attached when
opening the PR.)

---

Notes for reviewers

• BLE is opt-in per target; existing ESP8285 / ESP32 builds are
  byte-identical without the BLE_TELEM_ENABLED flag.
• WRITE property intentionally not exposed. The characteristic is
  one-way (notify only) for now.
• No changes to VRX / Timer backpacks.