[wip] Dynamic settings (part 1)

[mcspr]

edit: Closed. See current lights for an example. Too much merge changes to handle and we no longer need migrate.

ref: https://github.com/xoseperez/espurna/tree/v2

• Updated migrate.ino to use hardware.h (or, possibly, custom.h) entries as defaults instead of duplicating config inplace.
• Updated hardware-specific button setup for DUAL (Sonoff, Foxel) boards. (I hope I properly understood what it does)
• Updated button, relay, LED, lights and encoder modules to load configuration from settings.

Major difference from original v2 - no kv-only profiles (json headers). Classic header values are written to settings when cfg empty / 3 (current). Also, not overwriting board values and doing it only once.
Minor difference - no deallocating of relay / button / led / encoder etc lists to avoid memory fragmentation. Reboot is required to reinit them, (most) settings used from loop are reloaded though so that we can configure their behaviour.
MY92XX mapping is taken straight from v2, but exposed in headers as well.
Shorter encoder settings keys. Updated button action to fit into a single "structured" value.

IDK about MAX_COMPONENTS for now (maybe per-module instead?)
I have not touched key migration yet. No sensor config yet too. Although, it might be better to do separately with WebUI part.
Function names are still from the current version.
Initial migration might also need some more thought.

edit: words...

[mcspr]

Slight rework for migration converter. Since we can include files via #include at any point on the program, why not generate hardware that way?
pio run -t generate-hardware script creates special header files inside code/espurna/hardware/
SONOFF_BASIC.h looks like this:

setSetting("btnGPIO", 0, 0);
setSetting("btnMode", 0, 0 | 2);
setSetting("btnRelay", 0, 1 - 1);
setSetting("btnActions", 0, buttonStore(
0, 1, 4,
5, 7, 9));
setSetting("btnGPIO", 1, 14);
setSetting("btnMode", 1, 1 | 4 | 2);
setSetting("btnRelay", 1, 1 - 1);
setSetting("btnActions", 1, buttonStore(
0, 1, 0,
0, 0, 0));
setSetting("ledGPIO", 0, 13);
setSetting("ledLogic", 0, 1);
setSetting("ledMode", 0, 1);
setSetting("ledRelay", 0, 1 - 1);
setSetting("relayProvider", 0);
setSetting("relayDummy", 0);
setSetting("relayGPIO", 0, 12);
setSetting("relayType", 0, 0);
setSetting("relayDelayON", 0, 0);
setSetting("relayDelayOFF", 0, 0);
setSetting("relayResetGPIO", 0, 0x99);

Initial enumeration can be done, so we have unique board ids. If they are saved to some index file, ID change can be avoided when hardware.h order changes. But I still do not know it is really necessary to have.

[mcspr]

Note about "no deallocating of relay / button / led / encoder etc lists to avoid memory fragmentation."

Combined with change detection, to avoid allocating things multiple times, another thing to do is provide "moduleDeconfigure" / make "configure" two-stage. They'll need to run in a reverse order (assuming they are registered in setup, like configure).

[mcspr]

ee21f23#diff-efce85ec890efb697f7496c02c52e672
is an example of the most basic hw setup. header generation can instead just output to stdout and script can prepare something like this file.
however, device setup should have some method to clean up previous settings. for example, if we setup relays we need to remove every relay setting that is in the config before setting new ones
@xoseperez idk if you have any other ideas about configuration method. getsetting / embedis and eeprom can be a bit more intertwined, be somehow typed and maybe even have serialization in-out methods?

ps. i noticed a small library in rtos repo, which somewhat replaces both eeprom + embedis. did not find rotation support though:
https://github.com/espressif/ESP8266_RTOS_SDK/tree/master/components/nvs_flash/src
exactly the same api as for esp32 version