Convert ESP8266WebServer* into templatized model

[earlephilhower]

Supercedes #4912

Refactor the three versions of ESP8266WebServer and *WebServerSecure to a
single templated class. Use "using" to enable old, non-templated names to b
used (so no user changes required to compile or run).

Fixes #4908 and clean up the code base a lot.

Basic tests run (the ones in the example code).

No code changes are required in userland except for setting the SSL
certificates which now use a cleaner "getServer()" accessor and lets the
app use the native BearSSL calls on the WiFiClientSecure object.

@devyte should be proud, it removes virtuals...

[devyte]

Overall, nice work! I think I cried a little with so many virtuals removed. I see that request handler still has some, though.

I do have some comments about code structure, namespaces and refactoring, but it will take me a bit to go through the whole PR for the specifics.

In the meantime, some comments and questions:

1. Is there any bin size impact? IRAM impact?
2. This change means that the secure webserver is no longer a descendant of the non-secure webserver. As a result, any sketch out there that was implemented using the inheritance may no longer build. The way a user would need to address the change is to migrate any functions that were relying on the inheritance to a template version.
   => Breaking change.
3. As I understand things, the server and client must always match, i.e.: both must either be secure, or both not secure. Is there any scenario where a mix makes sense?
   I'm thinking:
   WiFiServer returns only WiFiClient
   WiFiServerSecure returns only WiFiClientSecure
   => maybe WiFiServer and WiFiServerSecure should have a type member that reflect the WiFiClient type they return. Then, the template parameter here would be unique: WiFiServerType. The client type would then be WiFiServerType::WiFiClientType.
   Why do this? it disallows the possibility of declaring a webserver with mismatched server/client types.
4. The templated object(s) should be put in a namespace. The specific types defined for secure/non-secure, i.e.: the using statements, should be outside the namespace in global space and reference the template with the specific type definitions. See polledTimeout for one way to handle this.
5. At a glance I see several methods that aren't really specific to the class they are implemented in, e.g.: urlDecode. It is good practice to move those out of the class into their own .cpp as standalone functions. This is particularly important when dealing with a template class, because each combination of template args will generate a copy of the method, and all copies will essentially be the same code.
6. One thing I have pending is to clean up the using namespace mime, which imports mime into the global space. If the template objects are moved into their own namespace, then mime could be imported there, and global namespace pollution would no longer be an issue.

[earlephilhower]

0. RequestHandler needs to be virtual without some major work since we need to keep track of multiple different ones with different implementations per-web-node. I don't see that changing anytime soon.

1. Bin size is about the same on things I tried. AdvancedWebServer actually shrinks by 704 bytes vs. master, and it uses 40 bytes less heap RAM as well. But, in the grand scheme, that's noise.

2. Are you saying an app subclassing WebServerSecure (class MyServer : public WebServerSecure {}) won't work? I think it's a no-op as you can subclass the template-ized just like normal, can't you? There's the possibility of object slicing, I guess, but the WebServer never returns itself, and only uses WiFiClient/WiFiServer which we don't expect to be subclassed. At that point, they'd need to make a template-ized instantation to get it going anyway, I think.

3. It's impossible for a WiFiServer to return a WiFiClientSecure, and vice versa. Let me see if I can use some typename magic.

4. Will do.

5. Agreed, but I was trying to minimized the refactoring involved. Wouldn't that be a breaking change? For a template-ized class, I thought all methods were template-type decorated so a naked "WebServer::parseURL()" declaration wouldn't be included as a class member. Moving the urlDecode to another class/global function would definitely be a breaking change (it's a public member). I would also suggest that apps will only be using secure or non-secure versions of the object, and not both, so duplicated code bloat is not going to be a common thing.

6. I think we moved mimetable to its own file just because of the PROGMEM segment problems. I think it can be moved back to the class...

[earlephilhower]

Got 3, 4, and 6 all taken care of.