Add non-blocking DNS for the async API via c-ares event-loop integration

[bjosv]

Even with c-ares enabled for timeout-bounded DNS, the async API still blocked the calling thread during DNS resolution. valkeyAsyncConnectWithOptions() resolved DNS synchronously before returning, using the same
blocking resolve path as the sync API. For applications using async I/O on a single thread, a slow DNS lookup stalls the entire event loop.

This PR builds on the c-ares sync DNS support (#323) and makes DNS fully non-blocking for the async API. When the connection is set up via the options path with a c-ares aware adapter (libevent), DNS resolution
is driven by the event loop, so no thread blocks during DNS.

How it works:

Async DNS is opt-in: it engages only when connecting via valkeyAsyncConnectWithOptions() with an adapter set in valkeyOptions.attach_fn, and only when that adapter implements the c-ares hooks. When c-ares is
enabled and such a connection is made:

1. valkeyAsyncConnectWithOptions() defers the TCP connect (VALKEY_CONNECT_DEFERRED): the endpoint is stored, but no DNS lookup or socket fd is created yet.
2. It then attaches the adapter (before initiating connect), so the adapter's hooks are registered first:
   • Libevent adapter (implements the c-ares hooks): starts a non-blocking DNS query via c-ares. The c-ares file descriptors and timers are registered with the event loop, so DNS completes as part of normal
     event processing without blocking.
   • Other adapters (libev, libuv, poll, etc.): do not implement the hooks, so valkeyAsyncConnectWithOptions() resolves DNS synchronously with a timeout and connects before returning. This still blocks briefly
     but is bounded by connect_timeout. These adapters can be upgraded to full async DNS by implementing the c-ares hooks.
3. Once DNS resolves, a TCP socket is created and connect() is called (non-blocking, as usual). The event loop then handles connect completion.

The legacy path (valkeyAsyncConnect() followed by a separate adapter attach) never defers, and always uses the blocking, timeout-bounded resolve, unchanged.

The connect logic (source_addr binding, SO_REUSEADDR, MPTCP) is consolidated in valkeyTcpConnectNonBlock() to avoid duplication between the async DNS path and the synchronous fallback.

Design decisions:

• Async DNS is deliberately opt-in via the options path. Any adapter without c-ares hooks, and the entire legacy connect-then-attach path, get blocking-with-timeout DNS. This keeps behavior predictable and
  requires no changes to existing adapters.
• The blocking fallback is centralized in valkeyAsyncConnectWithOptions() (taken when the adapter did not start async DNS, i.e. dns_state == NULL), rather than a per-adapter macro. Adapters need no changes.
• c-ares callbacks can fire synchronously (e.g. IP literals like 127.0.0.1). A done/failed flag pattern ensures cleanup happens safely outside the c-ares callback. An ARES_EDESTRUCTION guard in the callback
  prevents side effects when the channel is destroyed during context teardown.
• While the connect is deferred there is no valid fd, so valkeyAsyncConnectWithOptions() and valkeyAsyncSetConnectCallback() skip write-interest registration; the write watch is added once the fd exists (after
  sync connect, or from the DNS-completion callback). The shared _EL_ADD_READ/_EL_ADD_WRITE macros are unchanged.
• Async DNS is driven through the existing internal timer system (no new adapter timer hook).

Custom adapters:

Third-party adapters need no changes to remain correct: when c-ares is enabled, an adapter that does not implement the hooks gets a synchronous, timeout-bounded resolve performed by
valkeyAsyncConnectWithOptions() before the adapter is asked to operate on the fd. To get fully non-blocking DNS, an adapter implements the c-ares socket hooks (addCaresSocket/delCaresSocket) and calls
valkeyResolveAsyncStart() from its attach function, forwarding fd activity to valkeyResolveAsyncHandleEvent(). See the libevent adapter for a reference.

Testing:

• New ct_async_dns integration test exercising both the libevent async path and the standalone connect flow.