#77131

For #77131

- Rename `onDidEdit` to `onDidChange`
- Allow custom editors to fire a `CustomDocumentContentChangeEvent` that only marks the editor as dirty but does not enable undo/redo. The only way for editor to get out of this dirty state is to either save or revert the file

Fixes #93901

For #77131

Fixes #93963
Fixes #94515
Fixes #94517
Fixes #94527
Fixes #94509
Fixes #94514
Fixes #93996
Fixes #93913

This removes explicit edits from the API and reshapes the API to more closely match VS Code's internal API. The change also tries to better express the lifecycle of backups

Fixes #93995

* Fix rename on custom editors

* - Return disposable for register call
- Use `regsiterWorkingCopyProvider` to implement basic working copy provider
- Adding test

* Update src/vs/workbench/services/workingCopy/common/workingCopyFileService.ts
Co-Authored-By: NBenjamin Pasero <benjamin.pasero@gmail.com>

* Update src/vs/workbench/services/workingCopy/common/workingCopyFileService.ts
Co-Authored-By: NBenjamin Pasero <benjamin.pasero@gmail.com>

* Update src/vs/workbench/services/workingCopy/common/workingCopyFileService.ts
Co-Authored-By: NBenjamin Pasero <benjamin.pasero@gmail.com>
Co-authored-by: NBenjamin Pasero <benjamin.pasero@gmail.com>

#77131

Adds custom editor restoring to the backup restorer. This PR includes:

- Adds a `vscode-custom-editor` scheme that we use internally for custom editors. This ensures that each custom editor has it's own editing history (even if another custom editor opens the same resource).

- Make the backup restorer understand how to restore  `vscode-custom-editor` editors. This is done by adding a `IEditorInputFactoryRegistry` that lets the custom editor hook into the backup restorer

For #77131

- Use a class for `CustomDocument` instead of an interface. Extensions can now add their own data to a `CustomDocument` by sublassing

- Renamed `resolveCustomDocument` to `openCustomDocument` and require that extensions return a `CustomDocument`

- Exposed edits on `CustomDocument`

- Made the third parameter of `registerCustomEditorProvider` a generic options bag that takes a `webviewOptions`

Adds placeholder cancellation arguments to the custom editor api. These requests are currently never cancelled

For #92037

Ensures that we can open multiple types of custom editors are opened for the same resource, and that our dirty tracking works as expected in that case (by only marking editors of a given type dirty)

For #77131

Going back the the delegate based model for a few reasons:

- It gives us a better approach to add additional API hooks in the future (such as for rename)

- In practive, the capabilities were almost always the same as the `userData` on the document. It is rather confusing to have both `userData` and the capabilities 'on' the document

* Use the UndoRedoService for CustomEditors

For #90110

Changes custom editors (the ones not based on text) to use the UndoRedoService. This involved:

- Moving edit lifecycle back into the main process again (this is actually the bulk of the changes)
- Removing the `undo`/`redo` methods on  `CustomEditorModel`
- Using the undoRedoService to trigger undo/redo

For #91702

Co-authored-by: NMatt Bierner <matb@microsoft.com>

* IEditor => IEditorPane

* More panes:
* IVisibleEditor => IVisibleEditorPane
* ITextEditor => ITextEditorPane
* ITextDiffEditor => ITextDiffEditorPane

* imports - remove type alias

* More pane renames
* IEditorService#activeControl => activeEditorPane
* IEditorService#visibleControls => visibleEditorPanes

* More editor renames
* activeTextEditorWidget => activeTextEditorControl
* visibleTextEditorWidgets => visibleTextEditorControls

Fixes #91670

- Move model type logic out of `CustomEditorInput` and into two different implementations of `ICustomEditorModel`
- Add `CustomTextEditorModel` that owns a proper model reference to a text document. This should ensure the text document is disposed of if there are no more references to it
- Move most of the previous `CustomEditorModel` into `mainThreadWebviews` directly. This removes some of the indirection that was previously required (such as using `waitUntil`)

For #77131

Renames the activation event from `onWebviewEditor` to `onCustomEditor` to be consistent with the reset of the API

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.

Fixes #88414