This adds support for subdomain gateways introduced in go-ipfs v0.5.0,
specifically, one running at *.localhost subdomains

They key challenge was to ensure *.localhost DNS names resolve to
127.0.0.1 on all platforms. We do that by setting up HTTP Gateway port
of local go-ipfs to act as HTTP Proxy. This removes DNS lookup step from
the browser, and go-ipfs ships with implicit support for subdomain
gateway when request comes with "Host: <cid>.ipfs.localhost:8080" or
similar.

We register HTTP proxy using Firefox and Chromium-specific APIs, but the
end result is the same. When enableid, default gateway uses 'localhost'
hostname (subdomain gateway) instead of '127.0.0.1' (path gateway)
and every path-pased request gets redirected to subdomain by go-ipfs
itself, which decreases complexity on browser extension side.

By default, extension will now redirect from public subdomain gateways
such as dweb.link:
https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/
to the local one:
http://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.localhost:8080/wiki/

Redirect to gateway logic was path based, this is wip surgical refactor
to unify subdomain and path handling, hopefully decreasing maintenance
buden going forward

This is work in progress. Fixes will be applied in separate commits.

This avoids ibreaking IPFS content paths by converting them to URI params

It should not block the init()

Firefox 74 does not mark *.localhost subdomains as Secure Context yet
(https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c23) so we can't redirect
there when we have IPFS resource embedded on HTTPS page (eg.  image loaded from
a public gateway) because that would cause mixed-content warning and
subresource would fail to load.  Given the fact that localhost/ipfs/* provided
by go-ipfs 0.5+ returns a redirect to *.ipfs.localhost subdomain we need to
check requests for subresources, and manually replace 'localhost' hostname with
'127.0.0.1' (IP is hardcoded as Secure Context in Firefox). The need for this
workaround can be revisited when Firefox closes mentioned bug.

Chromium 80 seems to force HTTPS in the final URL (after all redirects) so
https://*.localhost fails. This needs additional research (could be a bug in
Chromium). For now we reuse the same workaround as Firefox.

To unify use of 127.0.0.1 and localhost in address bar (eg. when user opens an
image in a new tab etc) when Subdomain Proxy is enabled we normalize address
bar requests made to the local gateway and replace raw IP with 'localhost'
hostname to take advantage of subdomain redirect provided by go-ipfs >= 0.5

Chromium 80 already hardcodes localhost to loopback IPs, and we don't
want to add unnecessary permission as it may cause us fail review at
Chrome Web Store.

I also renamed the setting as its about overall Subdomain support on
localhost, even when HTTP proxy is not used.

This restores the proper way of opening webui in version provided by IPFS node.

Context:

Before subdomain gateway support was added, we loaded webui from gateway port.

Why? API port has a hardcoded list of whitelisted webui versions and it
is not possible to load non-whitelisted CID when new webui was released.

To enable API access from webui loaded via Gateway port, the Companion
extension removed Origin header for requests coming from its background
page. This let us avoid the need for manual CORS setup, but was seen in
the diff, was pretty complex process.

Webui is stable now, so to decrease maintenance burden we move away from
that complexity and just load version whitelisted on API port.

What if someone wants to run newest webui? They can now load it from
webui.ipfs.io.ipns.localhost:8080 (whitelist API access from that
specific Origin by appending it to
API.HTTPHeaders.Access-Control-Allow-Origin in go-ipfs config)

Closes #736