Add selectable UI color theme for color TFT displays

[estebanscdev]

Adds a runtime-selectable "legacy" dark theme (restoring the pre-refactor black background / green-yellow text palette) as an opt-in alongside the current "default" light theme, for boards using ST7735Display, ST7789LCDDisplay, NV3001BDisplay or LGFXDisplay (e.g. Heltec T096).

Fixes #3169

Selectable via Serial CLI: "set theme legacy" / "set theme default". DisplayDriver::applyTheme() returns false for an unrecognized/unsupported theme name, so the command rejects typos instead of silently falling back.

Persisted in NodePrefs.ui_theme (survives reboots and full power loss, written to flash via DataStore::savePrefs), reapplied at boot and live without reboot. DisplayDriver::getThemeCount() reports per-driver theme support so the command only works on boards with a color-capable display.

[IoTThinks]

set theme legacy" / "set theme default

This is cool.
However, there is no CLI in companions.

[shleepong]

Tested this on real hardware (Heltec Wireless Tracker V2, heltec_tracker_v2_companion_radio_ble), a few findings plus one suggestion.

Tested and working: set theme legacy / set theme default both work exactly as described, immediate effect, persists across a full power cycle (not just a soft reset).

One thing not obvious from the diff: on companion_radio_ble, the USB serial port only accepts plain-text set commands once "CLI Rescue" mode is entered (long-press the board's user button within the first 8 seconds after boot, see UITask::handleLongPress()). Outside that mode the port carries the binary companion protocol and silently drops plain text. Worth a one-line mention somewhere, since it cost us a while to figure out why set theme legacy had no effect over USB.

Current merge conflict, reproduced against today's dev: two files. In NodePrefs.h: trivial, another PR added cad_enabled/tz_offset at the same spot as ui_theme/theme, just keep both. In MyMesh.cpp: real conflict. checkCLIRescueCmd()'s old inline set-command chain (where the theme case lives here) has since been refactored into a shared handleCommand(), called from three places: the serial rescue console, CMD_RUN_CLI_COMMAND (the binary companion protocol, an app could expose this without any CLI), and onCLICommandRecv() (remote CLI over the mesh from a trusted contact). Moving theme into handleCommand() alongside set pin/set name resolves the conflict and makes it reachable from all three, not just serial, which also addresses @IoTThinks's point above about companions having no CLI.

Suggestion, a third theme. We like the mechanism a lot (persisted, runtime-selectable, minimal diff), but legacy's green-on-black wasn't to our taste. Since getThemeCount() already anticipates more than two themes, we prototyped a dark option: identical to default, only window_bkg/primary_txt flipped, nothing else touched. Tested side by side on the same board:

legacy	default	dark
legacy	default	dark

One thing that stood out testing side by side: on default, the unused part of the screen shows up as a stark white rectangle; on dark it just blends into the panel's black bezel, easier to read, and probably a small power-draw win. Happy to open a PR against your branch with the rebase plus this addition if that's useful, or just leave the diff here if you'd rather do it yourself.

Separately, we also prototyped driving set theme from an ordinary chat message (no CLI at all) via a synthetic local contact intercepting CMD_SEND_TXT_MSG before it touches the radio, see #3347 for the general idea. Might be worth keeping in mind as an app-side answer to the "no CLI in companions" gap, independent of this PR.