Support minimum-trust workspace

[justinmk3]

from #1821:

VS code 1.57 introduced a 'trust' feature that is applied to the current workspace, restricting extension access based on trust level. The insiders build allows individual extensions to have a trust level, by default they are untrusted. Untrusted extensions cannot be activated, thus failing the test. We are not particularly concerned with this functionality in regards to other extensions, so we will just disable it entirely when testing.

We should look into this more for our own extension as far as UX is concerned (what should our extension be capable of given a minimum trust level?)

Refer to this issue: microsoft/vscode#120251

Considerations for the toolkit (to be added to package.json):

capabilities:
	untrustedWorkspaces:
		{ supported: true } |
		{ supported: false, description: string } |
		{ supported: 'limited', description: string, restrictedConfigurations?: string[] }

By default, extensions do not support untrusted workspaces. This seems to be the best option for the toolkit for now. In other words, we do not need to update anything unless we want to add a description string for why we do not support untrusted workspaces.

Proposal

• Most Toolkit features don't need to write to the workspace, so we should be able to support untrusted model.
  • remote AWS explorer mostly reads/writes to the network (what trust level does network access require?)
  • CDK explorer can display its tree with just "read" access to the filesystem
• Trust is needed for:
  • write-level access: CDK deploy, SAM local run/debug
  • ?

[justinmk3]

• For minimum-trust VSCode is considering a "virtual fs" (VFS) layer. So we may want to prefer openTextDocument instead of lower-level filesystem functions: cdk explorer: take into account output from cdk.json #2180 (comment)

  openTextDocument will not avoid problem with workspace trust right now, as there is no problem yet - current implementation of Workspace Trust are declarative for extension ... But it helps future-proof as discussion is going to virtual fs (see microsoft/vscode#126913 for an example). openTextDocument is compatible with that, while direct fs.readFile is not.

  • This also will be relevant for VSCode "web": Toolkit can run in web browser (e.g. vscode.dev), avoid nodejs APIs #2205

    Extensions that run Node.js code that use OS-specific modules, or shell out to local executables are marked as unavailable.