For #77131
**Motivation**
While our existing webview editor API proposal more or less works, building an editable webview editor is fairly tricky using it! This is especially true for simple text based editors.
It'd also be nice if we could get bi-directional live editing for text files. For example, if I open the same file in a webview editor and in VS Code's normal editor, edits on either side should be reflected in the other. While this can sort of be implemented using the existing API, it has some big limitations
**Overview of changes**
To address these problems, we've decided have two types of webview editors:
- Text based webview editors. These editors used a `TextDocument` as their data model, which considerably simplifies implementing an editable webview. In almost all cases, this should be what you use for text files
- Complex webview editors. This is basically the existing proposed API. This gives extension hooks into all the VS Code events, such as `save`, `undo`, and so on. These should be used for binary files or in very complex text editor cases.
Both editor types now have an explicit model layer based on documents. Text editor use `TextDocument` for this, while custom editors use `WebviewEditorCustomDocument`. This replaces the delegate based approach previously used.
Adds a backup method to the custom editor API proposal. This method allows custom editors to hook in to VS Code's hot exit behavior
If `backup` is not implemented, VS Code will assume that the custom editor cannot be hot exited.
When `backup` is implemented, VS Code will invoke the method after every edit (this is debounced). At this point, this extension should back up the current resource. The result is a promise indicating if the backup was successful or not
VS Code will only hot exit if all backups were successful.
For #88719
With this change, instead of passing custom editor edit json back and forth with the extension host, we keep the original edit objects on the extension host. This means that we can pass extensions back the exact same edit object they first hand to us. It also means that edits no longer need to be json serializable.
If multiple instances of the same custom editor are opened for the same resource, the edit stack should be shared between them. This matches how we work with text files
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
