For web, it seems the most feasible direction for resolvers as we make
existing remote extensions 'web enabled' is to allow them to run in the
extension host. However, in no case will there just be a simple
websocket we can connect to ordinarily.

This PR implements a first cut at 'inline' resolvers where messaging is
done in the extension host. I have not yet tested them on web, where I
think some more wiring is needed to mirror desktop. Also, resolution of
URLs is not in yet. I think for this we'd want to do some service-worker
-based 'loopback' approach to run requests inline in the remote
connection, similar to what I did for tunnels...

Resolvers are not yet run in a dedicated extension host, but I think
that should happen, at least on web where resolvers
will always(?) be 'inline'.

Most of the actual changes are genericizing places where we specified
the "host" and "port" previously into an enum. Additionally, instead of
having a single ISocketFactory, there's now a collection of them, which
the extension host manager registers into when a managed resolution
happens.

…e-remote-resolver

…ote-resolver

…rity doesn't contain a '+' and is not in a 'hostname:port' format

…and extHostManagedSockets)

…ote-resolver

…r' into connor4312/inline-remote-resolver