Document how to leverage /dnsaddr for peer/content/routing

Related: https://github.com/ipfs/go-ipfs/issues/3926

Browsers have a few properties that can be exploited for use by IPFS:

- Users will visit many websites by themselves, typically visiting popular websites with good uptime.
- Browsers can resolve DNS by themselves (even using DNS-over-HTTPS).
- And related to this, websites have the option to create TXT records like `dnsaddr=/ip4/1.2.3.4/tcp/567/p2p/PeerID` so `/dnsaddr/domain.tld` can function.

This puts browsers in a unique position, browsers naturally discover many websites and thus many potential bootstrap nodes just from user behaviour, I propose encouraging browsers to exploit this behaviour to benefit IPFS bootstraping. Here's an example scenario to demonstrate:

1. A user goes to `https://website.tld` in their browser, this website happens to have TXT records which contain DNSAddr values.
2. The browser has a few options:
- Trust all - Add any DNSAddr values it finds to it's own bootstrap list.
- Trust whitelist - Have a whitelist of popular domains whose DNSAddr values are trusted by default (likely exposed in the GUI so users can expand the list).
- Trust user - Prompt the user, perhaps in the security padlock menu, if `https://website.tld`'s DNSAddr values should be saved.
3. If trusted, the browser will add the values found at `_dnsaddr.website.tld` to it's own bootstrap list.

This system provides resilience to bootstrap downtime and censorship by expanding the bootstrap list to include a wide selection of trusted entities, this also has the potential to reduce latency by contacting bootstraps which are geographically closer.