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 blocks the calling thread during DNS resolution. This happens because DNS is resolved inside valkeyAsyncConnectWithOptions() before returning, the same blocking call used by the sync API. For applications using async I/O to avoid blocking (e.g. serving many connections 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 libevent adapter is used, DNS resolution is driven by the event loop, so no thread blocks during DNS.

See commit "Add c-ares async DNS resolve for non-blocking connect", the other commits are from #323.

How it works:

When c-ares is enabled and an async connection is made, DNS is no longer resolved before the function returns. Instead:

1. The connect call returns immediately with no socket fd; DNS is deferred
2. When the application attaches an event-loop adapter (e.g. libevent), the adapter sees the pending DNS and acts:
   • Libevent adapter: 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.): resolve DNS synchronously with a timeout before proceeding. 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.

Design decisions:

• 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, preventing use-after-free.
• A VALKEY_DNS_BLOCKING_FALLBACK macro makes it trivial for adapters to opt in to the blocking fallback, one line per adapter.
• _EL_ADD_READ/_EL_ADD_WRITE macros suppress event registration while DNS is pending, preventing operations on an invalid fd.

Custom adapters:

Third-party adapters must add VALKEY_DNS_BLOCKING_FALLBACK(ac) to their attach function, or implement the c-ares hooks for full async DNS. See the documentation in docs/standalone.md.

Testing:

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