This change primarly adds a new `Open with...` entry to the explorer context menu. To do this however, I had to make a few other changes:

- Add a new explorer context key for availible editors
- Moved the editor select prompt into a new function called `openEditorWith`
- Use `openEditorWith` for the new `open with` explorer command as well as for the `reopen with` command

#77131

For #94408

Fixes #93380

Fixes #93857

Fixes #94368

Fixes #93850

Make sure restored custom editors correctly track being dirty even if they have not been activated yet

This reverts commit c817576c.

Add two extra checks:
- Don't prompt users if the file extension doesn't change
- Don't prompt if only optional editors are available

This reverts commit ebcc8208.

Fixes #92994

Fixes #93219

Fixes #81832

Attempts to support the following cases:

- An file is renamed to now have an extension that is supported by a custom editor

- A custom editor's file is renamed to no longer match the custom editor

In these cases, we try to prompt the user to see what to do

This is now handled by `CustomEditorInput.move`

For #77131

Adds a hook that lets extensions preserve the webview for a custom editor across a rename

Delegate to custom editor input on move. Eventually this will be hooked up to go back to extensions

Fixes #91862

* 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`)

This allows commands/contributions to enable/disable themselves based matching against the list of custom editors

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.

Fixes #81828