Safer settings reload and MQTT change detection

[mcspr]

• remove ws module change detection specific to MQTT_SUPPORT
• wait until loop to reload settings (to avoid issues when espurnaReload is called from async context: MQTT on -> off freezes the device #1115, Sonoff RF Bridge cant change "Boot Mode" of switch #1597)
• move const chars into String. should be slightly more heap, but avoids some of the copying and allows to use String convenience methods. mqtt-client APIs are given const pointer to the internal buffer.
  small optimization is to also set them to default inplace (String _mqtt_server(MQTT_SERVER);)
• apply placeholders in config()
• keep host (aka mqttServer) in memory for secure client, because it takes much more time to connect

[mcspr]

The best effect for settings RAM size is running Core 2.5.1 and up, with SSO optimization for String. Negligible fragmentation when strings are changing size (but still present when changing topic, only visible via heap fragmentation statistics ESP.getHeapStats(). see https://github.com/mcspr/espurna/compare/utils/fragmentation)

To keep memory in check with current setup - _mqtt_setting_string = String() invalidates internal buffer -> getSetting creates new one. If i underestimate "negligible" part, we can just invalidate all settings, like it was before with connection part, and read them all over again. How to do that though... is another question...

In general, something can be done to getSetting / Embedis / some other storage abstraction. Embedis itself already uses 4k of eeprom, in theory some String-like object can point directly to the correct position in that buffer. However, if something changes everything needs to be invalidated.