dnslink:// URIs

Since #544 we have specs for `ipfs://` and `ipns://` URIs.

`ipfs://` is quite straightforward but `ipns://` has always had a weird wrinkle in that the authority could be something you can resolve using a routing query for the IPNS namespace, or a DNS query for a TXT record as defined by https://dnslink.dev/

These are not the same thing, you cannot resolve an IPNS Record using DNSLink, nor can you resolve a TXT record via a routing query for the IPNS namespace.

We can't even parse the authority in the same way leading to janky looking constructs like:

```js
let authority

try {
authority = parseAsPublicKeyHash(url.hostname)
// hooray, it's probably an IPNS name
} catch {
// what is it? lol I don't know, maybe it's a domain name?
authority = parseAsDomainName(url.hostname)
}
```

Internally `@helia/verified-fetch` introduces a `dnslink://` URL protocol which simplifies handling and Helia has long separated resolution into the comparatively heavyweight (in terms of dependencies) [@helia/ipns](https://www.npmjs.com/package/@helia/ipns) and lightweight [@helia/dnslink](https://www.npmjs.com/package/@helia/dnslink) modules.

Perhaps DNSLink should be promoted to a first class citizen in the ecosystem and we should allow `dnslink://` URIs alongside `ipns://` and `ipfs://`?

Start by reading the ipfs:// and ipns:// specifications from #544, then compare the dnslink:// handling in @helia/verified-fetch with the separate @helia/ipns and @helia/dnslink modules. Done means the issue’s open design question is resolved and the specification clearly defines whether dnslink:// is supported and how its authority is interpreted.

Written by the indexing model from the issue text.