Add emscripten_dns_lookup_async / emscripten_dns_lookup_result

[guybedford]

This adds an asynchronous getaddrinfo on top of the getaddrinfo body from #27693, so a real DNS lookup under -sNODERAWSOCKETS can be awaited without blocking from any stack. Recreates the async API from #27182 on the landed approach.

getaddrinfo() under NODERAWSOCKETS can only wait for a node:dns lookup from a sync-proxied pthread or with ASYNCIFY/JSPI; on the main thread of a plain build it returns EAI_AGAIN. Event-loop reactors need a non-blocking form.

• emscripten_dns_lookup_async(node, service, hints) takes the same inputs and returns an fd that becomes readable (poll/select/epoll) once the lookup completes; numeric addresses and validation errors are readable on return. A pending lookup holds the runtime like a timer.
• emscripten_dns_lookup_result(fd, &res) reads the outcome: 0 with a newly allocated addrinfo list in *res (freed with freeaddrinfo), an EAI_* code, or EAI_AGAIN while pending. Nothing is allocated until a result is read, so the fd owns no C memory: dup shares the lookup and close has nothing to free.
• The fd is a plain FS stream with its own poll and wait-queue node, so it needs nothing from SOCKFS. Without NODERAWSOCKETS the API works the same, resolving synchronously.

The getaddrinfo body becomes $getAddrInfo, which allocates nothing and returns an EAI_* code or a descriptor (with a lookup thunk for a hostname under NODERAWSOCKETS); $writeAddrInfo mints the addrinfo list at the point ownership passes to the caller. getaddrinfo keeps its proxied / Asyncify.handleAsync / EAI_AGAIN dispatch unchanged.

Tests: sockets_node.test_noderawsockets_dns_async (with PROXY_TO_PTHREAD: numeric and error results readable at once, repeated reads each minting their own list, close without reading, dup sharing the lookup, close while pending, and a real localhost lookup awaited via non-blocking poll retries from the main thread or a blocking poll from the pthread) and other.test_dns_lookup_async for the default build.

Made with AI assistance under my review

[sbc100]

I'm not sure about using functions-that-return-file-descriptors as general model for async programming in emscripten.

How about we design the API to return a promise handle?

They separately we could find some way to add integrate promise handles into epoll? Actually would that even be necessary? Can't promise-resolution callback run even while waiting for epoll events? (i.e. do these DNS requests, or promise resolutions in general, have the feed trough the epoll system, or can they just work alongside it?)

[guybedford]

How about we design the API to return a promise handle?

They separately we could find some way to add integrate promise handles into epoll? Actually would that even be necessary? Can't promise-resolution callback run even while waiting for epoll events? (i.e. do these DNS requests, or promise resolutions in general, have the feed trough the epoll system, or can they just work alongside it?)

Right a promise handle can't work with epoll_callback, so must attach to thread-local promise callbacks instead.

Tokio on the other hand does in fact assume DNS futures are Send and can be sent between threads.

So we would need to likely pick either of:

• Promise-based with a main thread proxy (like dlopen_promise)
• Descriptor-based

[guybedford]

I've together a design for a unified async handling system in the stack of PRs ending at #27881 which then supersedes this PR.

The main approach is #27880 which allows async: 'auto' functions to receive a canWait final argument, and support for promise and fd variants. Review focused on that design is probably the best place for discussion further.