c/p PSTR attribute from Core files
dostring declaration with a macro instead of a scary looking boilerplate

saves varying amount of code space, mostly deals with our key and cmd strings

* stateless callbacks for mqttRegister. no module uses the lambda / std
  func with captures or otherwise, so it is kind of pointless to have it
* make sure we know topic and payload length at all invocations and
  not constantly trying to re-parse the same string over and over again
* clean-up api related to string parsing and make sure we allow
  stringview as input
* clean-up id / unsigned number parsing to work with views instead of
  using a generic strto{,u}l; sometimes this works, sometimes doesn't.
  as noticed previously with IR implementation, it *will* parse until
  the '\0' is found in the input and we can't interpret parts of the
  string without doing a copy for the strtoul
* fixing additional bugs caught in ifan, leds, sensors and lights that
  were causing build failures. plus, more range-based parsing code for
  the same reason as described above

- clean-up comparison routines and get rid of most of the casts
- reduces total number of calls to terminalRegisterCommand
  replace with a func accepting list of commands, which in
  turn get instantiated as constexpr PROGMEM arrays
- reduce ram fragmentation, since we don't need to alloc as much
- reduce flash consumption b/c of lambda -> standalone func conversion

rework more namespaces to use `espurna` root
makes internal references much easier (and shorter)

view class is not specific to settings, could use it across the app
remove duplicate code from IR

Settling on naming 'options' for enumerations (...possibly, everything
else in the future, would that make sense to store for 'setting' object)

Update terminal commands that were reporting status to also report a
full list of 'indexed' settings for the specific entity
Also updates the WebUI outputs which are (hopefuly) are already handled
as-is through the .js processing pipeline and the .html properties
receiving certain special string values

More namespacing and save ~2KiB of RAM by reducing the amount of loaded keys strings
However, ROM side of things may suffer b/c of template specializations for the
generic conversion functions when there are many different types involved.

Make sure we seamlessly handle 'convert' for the number and the string version.
And since it is a two-way map, update 'serialize' to use it as well instead of
either a simple static_cast<int> or duplicating the same strings used in 'convert'

Only string literals or static vars can be used in constexpr context,
but those can still be shoved into the flash region via PROGMEM.
Notably, PSTR(...) inside of a lambda is not a constexpr.

Some quirks to work out
- we don't 'enumerate' things through compiler, enum values may go
  missing since it is not a switch-case
- 'get' default value via query still requires us to know the settings
  key in the first place. and it still needs an explicit call to
  'serialize'
- sensor units are stringified as their display value.
  but, this also avoids two different 'string' versions of those
- EnumOptions struct instance may also be in PROGMEM, but one needs
  to be very careful to only allow aligned access to it's members
  (which currently means we can't use 8bit or 16bit 'enum class'es)

Make sure it could be moved further along, and the values inside of it
can be safely moved as well.

Also fixup commands that were missing ctx in OK / Error.

No need to duplicate argv::size()

Even if std::function compiles with the wrong (but compatible) signature

- more static flash strings and flash string formats
- println() will write \r\n when we mostly just use the \n
(and avoid mixing it up in the same function)

update custom action callback to also get the event
buttons fan actions
ifan buttons are handled through action instead of manually
fan settings and api are (sort-of) generic