Fix Captive Portal Examples for iOS devices

[bryceschober]

For my experience with an iPad mini running iOS 10.3.2, the captive portal examples just did not work. There were three issues, one known issue (#3225) with a simple temporary workaround, one a major blocking issue and one a minor usability issue but causing major user (me) confusion.

The known issue #3225 is worked around in 36731b3. I'm not expecting that to get pulled unless the fix is delayed. Hopefully that will just get fixed, and you'll cherry-pick only the other commits.

The major blocking issue was that the first "content" of the web page must start with "success" in order to spoof a valid internet connection to iOS devices. This is known to succeed in a <title>, but not consistently elsewhere. Without this spoofing, iOS may automatically disconnect from the access point, and in my case it always did so on the first network-list refresh after connecting.

The minor usability issue that caused major confusion is the name-serving of <anyhost>.local. Per WikiPedia, client are not supposed to refer to ordinary DNS for *.local hosts, which has been reserved for mDNS. Android devices seem to be permissive of the old wild-west style of serving *.local hosts, but iOS and probably OSX are strict. I moved the mDNS responder startup to global setup() for both access point and client mode. Without this, iOS devices will not obtain a route for esp8266.local, as defaulted in the example, until they after they have configured an upstream WiFi connection via http://192.168.4.1 and connected successfully. While this may seem like a minor usability issue, it caused me considerable confusion when implementing my own based on this example, and not realizing that mDNS was a global requirement for serving *.local hostnames, not simply for being a good citizen on some other access point's network.