Improve VS Code remote support when running as a "UI" extension

[ejizba]

In VS Code remote scenarios, users can choose to run as a "workspace" extension (aka in the remote environment) or as a "UI" extension (aka in the local environment). Per #954, we made the default "workspace". However, there are a few scenarios where users might want to run as a "UI" extension, for example:

1. In a dev container to avoid running docker in docker
2. If they have an ssh/wsl workspace open, but they want to work with their local docker instead

NOTE: When running as a UI extension, the best we can do is replicate the experience users have with a non-remote instance of VS Code. In other words, users aren't blocked from any functionality since they could just have two instances open (one remote and one local), but fixing this issue would mean they could have all functionality in once instance.

There are two main scenarios that won't work when running as a "UI" extension. In #1233, I added an error that blocks users from even trying:

NOTE: This warning can be disabled with the setting docker.showRemoteWorkspaceWarning

1. Terminal commands

Many of our features work by sending a command to the terminal. Unfortunately, when running as a UI extension, VS Code will always create a terminal in the remote environment. This causes errors like the following to occur because the container id doesn't exist in the remote environment or docker isn't even installed.

We could fix this in two ways:

1. Convert terminal commands to use Dockerode (which is ultimately just using REST APIs and skipping the terminal). The "prune" command is an example that uses Dockerode and works. The "view logs" command is an example that uses the terminal and doesn't work
2. Ask VS Code to provide an API to create a terminal in the local environment when running as a UI extension. This PR and this comment seem to imply it's already possible, but I never got it to work and the behavior is certainly not officially documented yet.

2. File System commands

A few commands interact directly with the file system (most importantly "Add Docker Files to Workspace"). These don't work when running as a UI extension because it will use the local file system which won't match the workspace. Users will see errors like this:

The only way I could see us fixing this is with an API from VS Code to somehow access the remote file system directly. Per #954 (comment), this API doesn't exist yet, but they are considering adding it.

Also note it appears Intellisense also doesn't work when running as a "UI" extension. This may or may not be related to the file system discrepancy.

[karolz-ms]

@EricJizbaMSFT and I talked. We could not think of any compelling remote development scenario that would involve the extension running as "UI" extension. Haven't seen any related feedback from users either. Closing for now--we will reopen if we learn something to the contrary.