Added SetupMenuSelectCodes

[moshe-braner]

A variant of SetupMenuSelect that stores the codes along with the labels, allowing arranging the menu as desired, the codes can be non-consecutive and out-of-order.

First implemented within the SetupMenuSelect class, but that (temporarily?) adds a bit of memory use to every select menu, so re-implemented as a derived class, thus no impact at all on use of the original class (for most menus). That was more work than that was worth, but I learned some things.

Example use:

SetupMenuSelectCodes * btm = new SetupMenuSelectCodes( "Wireless", RST_ON_EXIT, 0, true, &wireless_type );
btm->addEntryCode( "Disable", WL_DISABLE ); // 0
btm->addEntryCode( "Bluetooth", WL_BLUETOOTH ); // 1
btm->addEntryCode( "Bluetooth LE", WL_BLUETOOTH_LE ); // 5
btm->addEntryCode( "WiFi (Standalone)", WL_WLAN_STANDALONE ); // 4
btm->addEntryCode( "WiFi (Master)", WL_WLAN_MASTER ); // 2
btm->addEntryCode( "WiFi (Client)", WL_WLAN_CLIENT ); // 3

• note the order in the menu differs from the order of the codes. Can choose the order that makes most sense to the users. Also, if a future platform drops support for classic (non-BLE) Bluetooth, can simply remove the WL_BLUETOOTH line - SetupMenuSelectCodes can handle non-consecutive codes.

[moshe-braner]

Clarification: By "no impact at all on use of the original class (for most menus)" I meant that most menus would use the original class SetupMenuSelect, not this new class, and thus there would be zero impact. In some special cases one would want to use this new class, that would take a few more bytes for each menu that does use this new class.

If I understand it correctly, the scope of existence of the menu objects is such that they are destroyed when one leaves the parent menu. E.g., when one leaves the "Audio" menu then the "Volume Options" menu (direct child of Audio) is destroyed and its memory use reclaimed. Similarly when one leaves the "Volume Options" menu and returns to the "Audio" menu, then all the menus under "Volume Options" (default volume, max volume, etc) are destroyed - even before returning to "Audio". So there never are a lot of menus in existence at once, thus the memory use is not a big issue. Except when a menu with a lot of options is created, e.g., the list of polars. In that case there are more than 100 entries, and using the SetupMenuSelectCodes class would use up about 3 kilobytes more memory. It is silly that we need to worry about 3KB of RAM in 2024, but with the ESP32 we do need to. The free heap currently is about 70 KB.

[iltis42]

Looks great, hence needs some more testing of myself next days to ensure that nothing breaks using this method