For #109277

- Add more explicit two phase structure to api
- Make opener pass along label when registered

This workbench service handles opening external uris. Unlike the core OpenerService, it also has logic for configuring a default opener and prompting if multiple openers are availble for a given uri

* make PowerShell 7 default if available and show in choose shell menu

* misc feedback

* better handle ARM and use pfs everywhere also update pfs to handle AppExecLinks

* fix test

* move to async

* add logging

* powershell global tool is in the image apparently

* have path test be the same

* try/catch the readlink

* await exists

* fix test

* check what arch node is

* fix indexes

* address daniel's feedback

* have getProgramFilesPath return null instead

This changes makes a few changes to the openers:

- Move the opener prompting from the extension host into the main thread
- Make the external opener process two phases: get openers and then open. This would let us skip the trusted domain validation for extension handled links if we want to in the future
- Add lifecycle to commands used by the uri opener

For #109277

This change moves the extension uri opener contribution point to instead use the internal `IExternalOpener` api instead of the more generic `IOpener` api. This is required since external uri openers should see the resolved uri that has gone through port forwarding, not the raw uri that the user clicked on

#110226

This change allows remote extension to handle elevation if they want.
Fixes microsoft/vscode-remote-release#3922

Fixes #112446: Avoid timeouts in mirroring terminals to the extension host by assigning a temporary UUID to terminals created on the extension host side

See #113905

Fixes #112200

This is what was suggested in a reply comment to the following PR:

https://github.com/microsoft/vscode-docs/pull/4215

Fix #111348

Fix #110510

Part of #110498

Fixes microsoft/vscode-internalbacklog#1680