Decide about hickory in public API for DnsResolver

[b5]

Related to #3177

We need to implement a performant API for DNS resolution that we can own. We currently have a From<hickory_resolver::TokioResolver> for iroh::DnsResolver. This means hickory_resolver@0.25 would be in our public API, which means updating to a potential 0.26 would be a semver nogo during 1.0.

We agree we need to address this, but don't know what the API needs to look like yet. There are also open concerns about perf due to Boxing.

We can close this when:

• We have an API for providing custom DNS resolution that uses only types compatible with a 1.0 stamp of approval
• That implementation is at least 95% as performant as the current implementation (doesn't have to be the case for custom DNS resolution)

[Frando]

Implemented in #3473 and #3475