New apiRegister depends on `webServer()` returning a valid object.

- store name+callback pairs in list instead of a hash map
  remove vector reserve() overhead
- rework callbacks to expect flash strings
- comments...

Small difference is that now there's no way to know if command already
exists. Meaning, while we do override the existing callback, comman
names list will have more than one entry.

Flash strings are quite weird. In case we finally get all `const char*`s
in PROGMEM (which is the case for ESP32?), this could use a comment-proposed
method of having handlers per-module instead of handlers per-command.

Change the underlying command line handling:
- switch to a custom parser, inspired by redis / sds
- update terminalRegisterCommand signature, pass only bare minimum
- clean-up `help` & `commands`. update settings `set`, `get` and `del`
- allow our custom test suite to run command-line tests
- clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`)
- send parsing errors to the debug log

As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT`
- MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API.
- Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS.

Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :)
Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.

- general conversion from .ino modules into a separate .cpp files
- clean-up internal headers, place libraries into .h. guard .cpp with _SUPPORT flags 
- fix some instances of shared variables instead of public methods
- tweak build system to still build a single source file via os environment variable ESPURNA_BUILD_SINGLE_SOURCE

- Update sensor classes to support a generic way to store energy values
- Update sensor conversion code to deal with units and not magnitudes
- Add magnitude<->unit for sensors, generic way of defining used unit. Convert from sensor magnitude unit to the one used for display.
- Reset energy value based on index through external means (MQTT, HTTP)
- Rework energy timestamping, update webui with 'last saved' value

While this solves the energy conversion issues and we are finally seeing the real value, what I don't really like:
- KilowattHour and WattHour are separate enum tags, thus sort-of are different types altogether
- Conversion code in Energy object should probably use some generic 'ratio' calculation? (https://en.cppreference.com/w/cpp/numeric/ratio/ratio)
- We are still using runtime checks to do calculations and depend that sensor outputs only one specific value type.

Consider this a fix for energy display / storage and preliminary work on sensor.ino
Further sensor refactoring... soon.

* Config: remove prototypes.h

* fixup order

* word

* add missing

* fix warning while still using .ino

* bad at c/p;