This is no longer be needed. We still serve the webview code itself from a unique subdomain
This also removes the need for `serviceWorkerFetchIgnoreSubdomain`
* Simplify logic for webview resource uris
This change attempts to simplify the logic around webview resource uris by doing the following:
- Hard code the resource origin. We always will be hitting a service worker for these paths so they don't need to be dynamic (although in the future we may want to pull them from `product.json`)
This lets us remove these properties from the environment service
- Move remote handling from the resource loader in `asWebviewUri`.
- Remove the handling of http and https paths from the resource loader.
I don't think these cases can be hit any longer (although I need to confirm this with more testing for the web case). Instead I added a check to `asWebviewUri` so that we return the original uri if a http(s) uri is passed in
* Restore normalizeResourcePath
We still need to convert between a remote uri and one that our remote file system can read
* Fix test
* Restore passing in remote on extension side
* Remove only
When the core references `vscode`, we only want to import the types and never generate a real import (which will fail to load). Use `import type` to better enforce this
