* Promote webview Api to stable
Fixes#43713Fixes#28263
* Rename position back to viewColumn and mark viewColumn as deprecated
This allows us to more easily re-introduce a `position` property once we have gridlayout
* Move dispose methods onto webview itself
Also better hide a few 'internal' methods / properties on the panel / webview
* Revert "Move dispose methods onto webview itself"
This reverts commit 8fab6cc1a1.
* Move title onto webview panel
* Use _ names for private setters
* Remove unused emitter and dispose onMessageEmitter
* Preview internal emitters with _
Adds a new optional `CodeActionProviderMetadata`. This is passed in`registerCodeActionProvider` and contains a list of`CodeActionKinds` that the provider may return. The list is used for deciding when to show the `refactor` and `source action` context menus. It is not used for filtering the returned code actions
Possibly helps address #45383
* Split out `Webview` from `WebviewEditor` in API
**Problem**
The current proposed `Webview` interface has a few methods and properties that are very editor specific, such as `.reveal` and `.onDidChangeViewState`. These properies will not make sense if we ever allow webview to be displayed in other locations, such as in widgets
**Proposal**
Split the concepts of a `Webview` and of a `WebveiwEditor`. A webview is the html content itself. A `WebviewEditor` is an editor that displays a `Webview`
This would allow us to easily add other types of `Webview` owning objects in the future without having to document that some methods only apply when a webview is used as an editor vs as a widget
* Leverage notification progress support for progress API
fixes#44090
* only allow positive total/worked values
* drop total/worked in favour of percentage
* make sure to dispose CancellationTokenSource after use
* make the cancellation button optional
As discussed in #45994, move from using a uri to using a viewType. The view type is shared among all webviews of a given type, such as all markdown previews
Fixes#44575
