ServiceWorker-like protocol handlers for WebExtensions

> (this is placeholder issue, will be updated as we work on spec prototypes, discuss with vendors etc)

## Problem

Currently (2023Q3):

1. The web platform supports registering custom protocol handlers via [`navigator.registerProtocolHandler`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/).
1. WebExtensions in Firefox automate this and support registering custom protocol handlers via [`manifest.json/protocol_handlers`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers)
1. (somehow related) PWA manifest (at least in Firefox?) also automates this via [`protocol_handlers`](https://developer.mozilla.org/en-US/docs/Web/Manifest/protocol_handlers) field

The downside in **all the three cases above** is that `foo://` registered this way can ONLY do HTTP redirect to some other HTTP URL. There is no built-in way to return bytes to the renderer process directly.

Web platform has a way to return a synthetic byte response with custom headers: register a ServiceWorker to [resolve requests for specific scope and create `Response` objects](https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/respondWith).

Problem? Currently there is no way to leverage ServiceWorker for resolving protocols registered via `manifest.json/protocol_handlers`. Only redirect-based handlers are supported. ServiceWorker support is missing.

## Prototyping Solution

There is an opportunity to streamline the UX/DX around registering protocol handlers via manifest of extension (2) or PWA (3).

Both PWAs and WebExtensions (with Manifest V3) already have ServiceWorker capabilities, but we could focus on WebExtensions as it is safer environment with more clear boundary and UX around installation.

What is missing, is the ability for a protocol handler `foo://` to be a scope for a ServiceWorker that takes care of fullfiling all requests sent to the `foo://` scheme.

If we had that, browser extensions or PWAs would be able to fetch content-addressed content from `ipfs://` and perform hash verification on the client, the way that benefits user the most.

## IPFS Use Case is for WebExtension

- ipfs-companion WebExtension being able to use in-memory [Helia](https://github.com/ipfs/helia) (JS implementation of IPFS node) for resolving requests for IPFS content

### References

- wip spec work https://darobin.github.io/proto-handler-reqs/
- Mentioned during [WECG at TPAC 2023 (notes)](https://github.com/w3c/webextensions/blob/main/_minutes/2023-09-11-wecg-tpac.md)
- W3C discussion: https://github.com/w3c/webextensions/issues/451