Update the name resolver interface

[baarde]

This commit adds NIOStreamingResolver as a replacement for Resolver. This resolver is phrased in terms of resolving names to socket addresses, whithout any implication that DNS will be used. It also removes constraints on how results should be delivered, allowing an implementation to stream results as they arrive, without having to wait for a complete response.

Motivation:

Hello, I'm currently in need of a custom resolver for my HTTP client. But before opening a PR to add a Resolver to AsyncHTTPClient, I'd like to address the issues exposed by @Lukasa in #1487:

This Resolver interface bakes has two major limitations. The first is that it bakes in a strong knowledge of DNS: it's phrased in terms of A/AAAA. The second is that it does not allow result streaming: there are only two opportunities to deliver results.

So I've implemented the proposed interface.

Modifications:

This PR adds the proposed NIOStreamingResolver protocol and its associated NIONameResolutionSession.

HappyEyeballsConnector and GetaddrinfoResolver are updated to uses this new interface.

The Resolver interface is deprecated. The NIOResolverToStreamingResolver adapter is used to maintain compatibility with the existing implementations.

Name resolution tests are left mostly unchanged for the moment.

Result:

• The default name resolution is unchanged.
• Client using the Resolver protocol will get a deprecation warning.
• Implementations of the Resolver protocol may observe a minor change: if the connection to the target socket address succeeds or fails instantly (as sometimes happens when using EmbeddedChannel instead of the real network), the cancelQueries method may be called even though both A and AAAA queries have already completed. This is because the resolver delivering results and the resolver completing are now two separate events, and HappyEyeballsConnector may terminate and clean up its resources between the two events. This can be seen in testIPv6OnlyResolution and testAQueryReturningFirstThenAAAAReturns. However it is unlikely to have an impact in the real world as the cancelQueries method is probably always ignored.

Unresolved:

• I haven't implemented the proposed NIONameResolutionSession.Hints type as neither HappyEyeballsConnector nor GetaddrinfoResolver would currently use it. Do we want it now? Or should we wait until we have a real use for it?
• I haven't added new tests yet, nor modified existing ones (beyond what was strictly necessary to make them pass). I'd like to make sure every one is happy with the new design first.
• Streaming results will break Happy Eyeball's expectation that results be sorted according to RFC 6724. At some point we will have to sort the results in HappyEyeballsConnector. But I think we can address that later.
• Should we make NIOStreamingResolver Sendable?