Add support for resolving wildcard subdomains *.localhost

This would solve...

In popular browsers, subdomains of localhost (e.g. http://myserver.localhost) all resolve to loopback [::1, 127.0.0.1]. This is also also specified in the fetch spec.

• Chrome: 2015-03 http://crrev.com/322452 (linked from comment)
• Firefox: 2020-01 https://bugzilla.mozilla.org/show_bug.cgi?id=1220810
• WebKit: not implemented yet https://bugs.webkit.org/show_bug.cgi?id=160504

References:

• https://fetch.spec.whatwg.org/#resolve-an-origin: “If origin’s host’s public suffix is "localhost" or "localhost.", then return « ::1, 127.0.0.1 ».”
• https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 (2013): “ The domain "localhost." and any names falling within ".localhost." are special”… “Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries”

The implementation should look like...

Extract the public suffix, compare it to localhost and localhost. before calling dns.lookup.

I have also considered...

Additional context

This could also be a workaround for a bug resolving non-wildcard localhost itself #1602, since glibc getaddrinfo mistakenly filters out the localhost loopback ipv6 address when you pass in the ADDRCONFIG flag (https://sourceware.org/bugzilla/show_bug.cgi?id=14969).

Start by locating the hostname-resolution path that calls dns.lookup, then compare its behavior with the Fetch specification and RFC 6761 references. Done means wildcard subdomains such as myserver.localhost resolve to loopback addresses before ordinary DNS lookup, with the relevant tests passing.