CRSF telemetry: let users choose which frames are sent

[Raffi1202]

Problem

With ELRS the telemetry downlink is saturated at the usual settings. INAV offers every scheduled CRSF frame type at 10 Hz. The ELRS receiver keeps only the newest frame per type in its queue (RXOTAConnector.cpp, overwrite by type), so in practice every type gets the same share of the downlink. Frames that nobody uses on a given model still take their share and slow down the ones that matter.

Typical plane with GPS and baro (attitude, battery, flight mode, GPS, baro/vario): 13 OTA4 telemetry packets per round. Update rate per frame type, calculated from the ELRS 4.1 source (not measured, retries not included):

ELRS setting	Telemetry data packets/s	Update per frame type
250 Hz 1:16	~13.7	~1 Hz
150 Hz 1:8	~16.7	~1.3 Hz
250 Hz Std (1:64)	~2	every ~7 s

Leaving out attitude and flight mode (4 of 13 packets) raises every remaining type by ~44 %. GPS and battery only: ~+86 %. On a link that is not saturated there is no gain, because INAV's 10 Hz is then the limit.

Use case that triggered this: logging GPS position and GPS time on the ground via the ELRS TX Backpack (see #12068). Attitude, flight mode and vario are not needed there, but they slow down GPS.

A higher telemetry ratio helps more (1:64 -> 1:8 is ~8x), but it costs RC packets. Leaving out frames costs nothing on the link.

Proposal

• One setting per CRSF frame type, stored as a bitmask in telemetryConfig. Default: all on, so nothing changes for existing users.
• initCrsfTelemetry() only schedules enabled frames. Frames that are switched off are left out of the schedule, not sent empty (see Fix CRSF airspeed, rpm, and temperature telemetry corruption from PR #11025 #11189).
• Configurator: checkboxes in the Receiver tab next to the existing telemetry options, shown when the receiver is CRSF.

Prior art

• Feature: selectively enable/disable individual telemetry sensors #3221 (2018, closed as stale): same request for S.Port. teckel12 measured 16 -> 13 sensors as "about 19% faster, just not enough to notice".
• Refactor CRSF and SmartPort telemetry #11142 / * Refactor CRSF and SmartPort telemetry #11296 (error414): CRSF/SmartPort refactor with per-sensor rates; closed by the author as a draft.
• Betaflight: telemetry_disabled_* bitmask, honoured by CRSF, SmartPort and GHST; CLI only.
• Rotorflight: per-sensor intervals with a scheduler that knows the link budget.
• Proposal: `MSP2_INAV_TELEMETRY` — subscription-based push telemetry over MSP #12049 (MSP2_INAV_TELEMETRY): subscription with a rate and a field bitmask per block, for MSP.

Questions

1. Is on/off per frame enough, or should it be a rate per frame (like mavlink_port1_*_rate)?
2. CRSF only, or one sensor mask shared by CRSF, SmartPort and GHST like Betaflight?
3. Should the selection model be shared with Proposal: `MSP2_INAV_TELEMETRY` — subscription-based push telemetry over MSP #12049?
4. The new field bumps the PG_TELEMETRY_CONFIG version (12 -> 13), which resets the telemetry settings to defaults. Acceptable for 11.x?

[error414]

I close my PR because it took lot of memory and it's not easy to use, You need lua script to translate "universal sensor" to specific sensor. It was based on rotorflight, but for rotorflight was created nice LUA script.