Extending on the new WiFi-less startup and new power saving APIs in ESP class

[dok-net]

Implementing in ESP class the sleep modes that are pertinent with and without WiFi:

• forced light sleep, with/without timeout, with/without GPIO wakeup.
• automatic light sleep when idling, like during delay()
• automatic modem sleep when idling, like during delay()
• never sleeping (NONE_SLEEP_T)

For sketches without WiFi, additional RF powersaving mode support on power up and deep-sleep resume. Could avoid power use spikes and delays during startup.

WiFi default is "off" now, don't force sleep in setup() of examples that do use WiFi.

Examples for the new modes.

Fixes #7055 - thanks to @Tech-TX for pointing this out.

[Tech-TX]

I've been doing some testing for Dirk for a week or two, and have re-verified the correct operation of this last commit 637f5d6. The timers are properly re-attached after Forced Light Sleep, which I never could get to. Thanks, Dirk! The three examples function as expected, and all power saving modes hit the right current levels. No surprises, no warts that I've seen. For people using servos I'd stop them before Forced Light Sleep, else they may slam the stops when PWM halts. You can restart them afterwards.

In order to maintain WiFi across Forced Light Sleep you must sleep the modem cleanly before ESP.forcedLightSleepBegin(). I tried it the dirty way and WiFi wouldn't recover after Sleep. I tested WiFi.forceSleepBegin(0xFFFFFFF) (sleep forever) before putting it to sleep, and WiFi.forceSleepWake() after it had recovered from ESP.forcedLightSleepEnd(). No problems restoring the connection that way.

I need to revisit https://github.com/esp8266/Arduino/pull/6989 and clean that demo program up with the new API calls. When merged this closes https://github.com/esp8266/Arduino/issues/7055

I didn't review all of the code, merely tested the functionality very thoroughly.

[Tech-TX]

Utterly side comment, not required for this PR: I think I just figured out how the NodeMCU folks implemented something like 'wake from Forced Light Sleep with a CHANGE level interrupt', not just the HI LEVEL and LO LEVEL specified in the API Reference.

If you read the pin level of the interrupt pin just before going to Forced Light Sleep and set the interrupt to the opposite level, it accomplishes the same thing. Going in with a HIGH on the pin, set the interrupt to LOW and vice versa. Then any change during Forced Light Sleep wakes it, and the user doesn't care what state the pin had been in immediately prior to Sleep; any change wakes it up.

Since the interrupt attachment is done outside of this API wrapper, the end user would have to do this in their code.

Due to the delay() needed to put it to Sleep, there's a small but nonzero chance that the pin might change after you read it, and it wouldn't come out of Sleep at all without a Reset as the Sleep logic is all mangled.

[dok-net]

With latest commit, completed migration of ESP8266Wifi recently PR'ed to the new Esp class API proposed here.