Separates the OSD elements position/visible/profile flags from the `osdConfig` PG and moves them to a new `osdElementConfig` PG. Allows new elements to be added without having to constantly update the PG version for `osdConfig`.
- Add displayWriteFontCharacter() for font writing, removing all max7456
specific code.
- Add displayIsReady() for asynchronous display initialization
- Add displayBeginTransaction()/displayCommitTransaction() for display
transactions, which allow performing complex drawing operations without
flickering
- Add displayGetCanvas(), which retrieves the canvas associated with a
display (if it has it)
- Add canvas implementation for pixel based access for a display
- Add FrSkyOSD driver and displayPort driver
- Enable FrSkyOSD driver for targets with flash > 256
- Rename max7456_symbols.h to osd_symbols.h
Isolates and prevents changes to runtime active features. Any changes to enabled features are deferred until after a save/reboot. Simplifies the previous logic.
Prevents potential failures when features are changed at runtime but the underlying code is not capabile of dynamic reconfiguration.
Instead of having individual menus for RTC6705, SmartAudio, and Tramp, Now there is a single VTX menu that detects the type of active device and redirects to the appropriate protocol menu.
Reduces confusion and chances of erroneously using the wrong VTX menu.
Fixes a problem where the Tramp menu could be used to change band/channel/power even though the VTX was a SmartAudio device.
If the VTX is not configured or not communicating, a more informative message will be presented rather than a partially populated protocol menu. For example:
```
VTX NOT RESPONDING
OR NOT CONFIGURED
> BACK
```
Extends the CMS menu capabilities by adding an optional `redirectCheck` function that can conditionally return a menu that should be redirected to instead of the current menu. This redirect happens before any processing happens for the original menu. Adds flexibility to make the CMS menus have a more dynamic aspect.
Previous logic was updating updating the DMA buffer for all possible LED positions (32) regardless of how many were used. Since there are 24 bytes per LED, this performed a lot of unnecessary processing in cases where the user had less than 32 LEDs configured.
Also includes a bug fix in that if the LED count was decreased (like making changed using the Configurator LED tab), the now unused LEDs at the end of the string would remain on at the last color applied. Now they will be properly turned off. The bug was minor as it was resolved by a reboot, but made setup using the Configurator confusing since changes made are reflected when the user clicked the "Save" button (which does not reboot).
