resolvers: support nesting and exec server (#185169)

This adds support for nesting remote authorities via passing through
ExecServers.

- An authority like `wsl+Ubuntu@tunnel+my-pc` is parsed into
  the chain `tunnel+my-pc` -> `wsl+Ubuntu`
- An extension for the `tunnel` prefixed is resolved. We expect the
  resolver to implement the new `resolveExecServer` method.
- Resolution continues. `wsl+Ubuntu` is the last resolver, so the
  `resolve()` method is called and the exec server is passed in its
  `RemoteAuthorityResolverContext`

Currently the ExecServer is typed as `unknown` in the API. _Maybe_ we
want to make it real API in the future, but I don't want to do this
until it's generalized beyond a single consumer (WSL).

This also has adds utility method `getRemoteExecServer` to get an exec
server for a given remote. This is used by WSL to probe information
about a tunneled machine even when WSL isn't opened (e.g. to get the
list of distros to shop.)

The new `@` handling should not break remotes. WSL doesn't use `@` in
its remotes, SSH and containers both hex-encode information contained
in authorities. Codespaces does put the codespace name in the remote
authority, but it doesn't seem like it's possible to get `@` in those
names, since they're generated either randomly when opening a template
or from a repo name (where @ is not allowed).

src/vs/workbench/api/common/extHost.api.impl.ts

@@ -1042,6 +1042,10 @@ export function createApiFactoryAndRegisterActors(accessor: ServicesAccessor): I
 				checkProposedApiEnabled(extension, 'resolvers');
 				return extHostLabelService.$registerResourceLabelFormatter(formatter);
 			},
+			getRemoteExecServer: (authority: string) => {
+				checkProposedApiEnabled(extension, 'resolvers');
+				return extensionService.getRemoteExecServer(authority);
+			},
 			onDidCreateFiles: (listener, thisArg, disposables) => {
 				return extHostFileSystemEvent.onDidCreateFile(listener, thisArg, disposables);
 			},