Connect to known providers if dnsaddr exist for redirected gateway

Capturing suggestion from https://github.com/filecoin-project/slate/issues/342#issuecomment-700948648

> companion could look up a dnsaddr record for the domain when it encounters IPFS urls. So `slate.host` could have a txt record like `/dnsaddr/slate.host/tcp/4001/ipfs/QmNodeyNodeNode` and while it redirects [`slate.host/ipfs/..`] requests to the local daemon, also try and connect to the suggested peer, to help with situations where it is difficult to publish all the provider records to the dht.

Initial thoughts:

- We could do DNS TXT lookup in companion, eg. leverage Cloudflare for DoH lookup (some notes in https://github.com/ipfs/helia-ipns/issues/53)
- ...but a better way would be to have upstream support for resolving `/dnsaddr` in https://github.com/multiformats/js-multiaddr/issues/94
- There is no API in browsers to do this, so we introduce security implications around leaking browser history to DoH provider that may be different than the OS-or-browser-level one chosen by the user

Alternative explanation:
> yes, so its like a hint for user agent that is about to load content from public gateway, and instead wants to use native IPFS. user agent reads DNS TXT record for that public gateway and learns its multiaddr, and loads data from IPFS + preconnects to that gateway in best-effort fashion.
>
> rationale is: if someone linked to that gateway, that gateway's ipfs datastore most likely has the data, so it makes sense to preconnect to it

Review the linked Slate discussion, the js-multiaddr issue 94, and the helia-ipns issue 53 notes to understand the proposed dnsaddr resolution paths. Check browser and DoH security constraints before defining an approach; done means the companion can safely discover the suggested peer and best-effort preconnect without exposing unintended browsing data.

Written by the indexing model from the issue text.