Decouple nested resolvers

[aeschli]

To run WSL inside a tunnel, the tunnel extension currently knows about the WSL extension and vice versa.

a. When a tunnel is open (authority: tunnel+...), the WSL extension asks the tunnel extension for an exec server to test if the connected machine is Windows machine and to query distros. based on that it provides commands and populates rremote views.

b. When opening a WSL inside a tunnel we nest the authority: tunnel+Surface-PC++wsl+Ubuntu
The tunnel extension starts resolving the first part (tunnel+Surface-PC) and then hands over resolving to WSL.

Given that we want to add more nestable resolvers (containers, ...), we could avoid the coupling by having the VS Code to the coupling.

a. A resolver can not only make a connection but also provide an exec server:
ManagedResolvedAuthority: connectToExecSever(). Tunnels would implement that when resolving an authority tunnel+....

RemoteAuthorityResolver will get an additional (optional) function resolveNested(nestedAuthority: string, execServer: ExecServer).
It would be implemented by the WSL resolver and is called when the authority is tunnel+Surface-PC++wsl+Ubuntu.

b. vscode.env.onDidResolveExecServer: Event< ExecServer> allows to get a hold to a ExecServer when a remote is open that supports that.
It is called when the authority starts with tunnel+Surface-PC. WSL would register there and contribute commands (and remote views).

[connor4312]

We now have a proper .d.ts api for this