For #77131

This reverts commit 544b0abf.

This currently is not connected to any actual actions in the editor

Fixes #63052

Fixes #62103

This documents the current thinking on the custom editor api. The current api proposal is not actually implemented yet

Preserve comment thread collapse state across extension host update messages, fixes https://github.com/microsoft/vscode-pull-request-github/issues/1400

Part of #81574

Fixes #82128

Instead pass over the extension when resolving the extension itself

This reverts commit 7f5a4a3f.

This reverts commit 7f5a4a3f.

This reverts commit afa911d9.

fix #82203

Part of #81574

#81131

Split out from #77131

The current webview editor api is very procedural. This model has some problems when it comes to supporting editing resources, but actually does make a lot of sense for webviews that aren't backed by real file system resources. For example, if you have a webview that edits some document in the cloud, you should not be required to implement a custom file system provider just to enable basic saving.

This change moves the `onWillSave` and `webviewEditorState` properties back onto `WebviewPanel` instead of keeping them specific to `WebviewEditor`. The save implementation does not fully work yet, as the will require #81521

This fixes an issue where webviews for custom editors did not have any associated extension information, which caused them try reading `file:` uri resources instead of remote uri resources

For #81131

We had trouble coming up with cases where extensions could actually reliably dispose of the resolved uri

- Add a resolveExternalUri function to the opener service. This service already has to know how to resolve external uris so it makes sense that the function lives there

- Move the tunneling logic for desktop into window.ts

- Make result of resolve disposable

Introduced DebugSessionOptions passed to debug.startDebugging which
encapsulated DebugConsoleMode to control this behavior.