Loading screen for non-local and redirected content

#### Important!
The solution implemented under this issue should be implemented with identical UX for WebUI, too: see issue https://github.com/ipfs-shipyard/ipfs-webui/issues/991.

IPFS Companion should improve experience of loading CID in `main_frame`, namely situations when:

- waiting for content routing/discovery
- redirecting to a different (local, public) gateway for the first time
- this includes recoveringfrom dead HTTP links

### Current UX

#### Slow content routing

An empty, white page displayed until bytes start arriving from IPFS.

Fast for local content, but slow for remote, especially if content is only at a single node, no peer hints (#722) are available, and we need to query DHT for providers.

#### Redirect

No warning, no info what is happening, we just redirect. This is a problem when content takes some time to be found. User is redirected and stares at a white screen. Browser vendors often don't update address in location bar until first byte starts arriving, which looks like "IPFS Companion broke the website".

### Proposed Change

Detect IPFS request for root document (`request.type === 'main_frame'`) and display educational "loading screen" until data is available in local datastore of IPFS node. It should inform user that location of data is being discovered using [methods].

We should do similar thing when redirecting DNSLink website or gateway for the first time: tell user what is about to happen, give option to skip the redirect info in the future for this DNSLink website/gateway (see uBlock below).

To make it easier to test, it should be an opt-out Preference.

### Prior Art

### browser.tabs.update

I've been thinking about use of DataURLs ([blocked by this bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1552715#c7)), but received [suggestion](https://bugzilla.mozilla.org/show_bug.cgi?id=1552715#c7) to reuse a technique from uBlockOrigin:

> Have you entertained just opening an extension page instead of redirecting outright?
>
> That is, block the network request and instead load your extension page using `browser.tabs.update(...)` with whatever query parameters needed to
configure the rendering of the page.
>
> An example of such technique is [used in uBlock Origin](https://github.com/gorhill/uBlock/wiki/Strict-blocking) to warn a user before loading a navigated-to web page.

### showing what is happening

- Jim is experimenting with terminal-based visualization what happens behind the scenes: https://github.com/jimpick/go-ipfs/blob/jim/network-logging/README.ipfs-spy.md
- Related discussion in go-ipfs: _Gateway Browser UX - Loading screens?_ https://github.com/ipfs/go-ipfs/issues/7729

cc https://github.com/ipfs-shipyard/ipfs-companion/issues/710