Fixes #79424

This file depends on dom api so it should live in browser instead of common

#78168

For #77132

This change attempts to do the following:

- Encapsult most of the logic for handling the webviews used for webview editors into a new WebviewEditorOverlay class
- Greatly simplify WebviewEditorInput and make it take a webview when it is created
- Move the webview creation logic up into the webviewEditorService instead of having it be inside the webviewEditor class itself

This aim of these changes is to make it possible to re-use more of the webview logic for custom editors

Fixes #77132

Add support for loading webviews from and endpoint that looks like:

```
https://{{uuid}}.contoso.com/path/to/some/commit/index.html
```

This lets us serve each webview from a seperate origin

This ensures we still work even if there is no base uri set

- Reducing duplicated code
- Clearer event names
- Extract methods
- Store data instead of requests

Hooks up a prototype of how we could support some types of port mapping inside of webviews. It uses the same service-worker based approach that we use for loading local resources inside of webviews.

This does not work for loading iframes however as iframe `src` requests go to the service worker of the `src` origin (not the service worker of the parent that contains the iframe). Not sure if this can be worked around. Two alternatives if we can't:

* Add api for getting the mapped port.
* Dynamically rewrite the input html

Both are not ideal as they may require eagerly opening tunnels (we open them lazily at the moment)

These block top level reloads. We only want to prevent the iframe itself from navigating

This does not need to happen in the webview itself

## Problem
We use a custom `vscode-resource` protocol to control access to local resources inside of webviews. This will not work on the web, but we still would prefer a way to intercept webview requests from the main client

## Proposed solution
Move webviews into their own origin and register a service worker on this origin. This service worker can talk with the outer iframe of our webview. When a request for a resource comes in to the service worker:

* In the service worker, add the request to a map and post a message back to the client saying we want to load this resource
* The outer iframe gets the message from the sercice worker and forwards it to our main process
* This process handles the message and use the normal file system api to read the resource (also restricting which files can be read)
* We post the result back into the inner iframe which fowards it back to the service worker
* The service worker now resolves the pending request.

The prototype version in this change works but does not correctly handle multiple clients existing at the same time (plus probably a lot of other edge cases too)