We should consider implementing Happy eyeballs v3 when it becomes a real RFC

**Is your feature request related to a problem? Please describe.**
It's not really much of a problem more than it is a suggestion but it seems we got a new kind of connection technique on our hands which is happyeyeballs-v3. While It's still in it's drafting phase but it will likely before a real RFC in the future. It talks about adding asynchronous systems for dns resolving which I see [pycares](https://github.com/saghul/pycares) and [cyares](https://github.com/Vizonex/cyares) being great candidates for that and Cyares already implements many of these newer dns queries that are mentioned in the RFC Draft.

**Describe the solution you'd like**
Will probably need to add a DNS section to this library, otherwise I would be willing to make my own under the name __aiohe3__ or something (he3 meaning happy-eyeballs v3) with both [pycares](https://github.com/saghul/pycares) and [cyares](https://github.com/Vizonex/cyares) implementations to utilize.

**Additional context**
RFC Draft in question - https://datatracker.ietf.org/doc/draft-ietf-happy-happyeyeballs-v3/

The issue names no repository files, tests, or entry points. Start by reading the Happy Eyeballs v3 RFC draft and comparing its DNS requirements with this library's pre-resolved-host scope, then review the proposed pycares and cyares options. Done would require a concrete implementation scope once the draft becomes a real RFC.

由索引模型根据 Issue 内容生成。