Implement epoll APIs in the JS filesystem

[guybedford]

Updated version of #27201, based to #27206. Also includes an integrated callback model for #27181, to fully verify the unified wait/callback approach on epoll semantics.

Resolves #5033, #10556.

Adds epoll_create1, epoll_ctl, epoll_wait, epoll_pwait and a non-blocking JS-callback variant, emscripten_epoll_set_callback, on a single fd readiness model shared with poll().

Readiness in the JS FS system is already event-driven in SOCKFS and PIPEFS. The integration point is the per-inode wait-queue, having each FS node carrying a listeners set. Producers then call notifyNodeListeners(node, flags) on ready transitions. There is no separate or parallel readiness machinery - it integrates directly with the existing model. pollOne(fd, events) is reused on the same readiness definition.

Per standard epoll semantics - epoll_ctl ADD installs a new listener on the watched node. If items are already ready they are added to the ready list. That listener then appends the registration to the epoll's ready list for waking. The epoll_wait consumes the ready list, re-checking each item against its current mask via pollOne.

• EPOLLONESHOT clears listeners to avoid unnecessary callback firing. EPOLL_CTL_MOD can then re-arm them again.
• EPOLLET is implemented correctly to avoid refiring items that remain ready
• EPOLLEXCLUSIVE is passed for listeners allowing only one wake for multiple epoll listeners to avoid the "thundering herd".
• When exceeding maxevents, draining follows Linux-like semantics in supporting round-robin ready calling. To achieve this without losing performance, a doubly-linked list is used for the registrations. A simpler set / array with copying could be used alternatively if we don't want to use this approach.
• Registrations key on the open file description (the dup-shared stream state), matching Linux: closing a watched fd and reusing its number for a different open does not resurrect the registration onto the new fd.
• Active listeners on an epoll maintains keepalive, so long as the set of epoll descriptors are non-terminal.

To support JS callbacks without JSPI/threads, a new emscripten_epoll_set_callback is implemented. This was implemented here to verify its comprehensive integration with all of the implemented epoll semantics, but could also be split out into a separate PR if necessary. It allows registering a persistent consumer on that same ready list as the epoll - the runtime delivers the ready set to the callback on each progress as if it were responding to an epoll_wait, but on the next tick after exiting the stack with no blocking and no ASYNCIFY/JSPI. It is armed once for the entire epoll, then consistently re-fires on the next tick while the set stays ready (so level and overflow drain as a blocking epoll_wait loop would). There is at most one callback per epoll (a second call replaces it; a NULL callback unregisters). Full integration with ready-list semantics work out naturally as it is just another consumer of the ready list. EPOLLET / EPOLLONESHOT EPOLLEXCLUSIVE / maxevents all work out and apply to this callback design, so a single callback can fully integrate with normal epoll semantics.

Most of the diff is tests, covering these semantics in depth including error handling, level versus edge reporting, nesting and ELOOP, fd-close auto-removal, JSPI and pthreads, real sockets, deregistration. For emscripten_epoll_set_callback comprehensive tests are added for integrating with JSPI blocking epoll_wait in parallel and verifying both deterministically drain the same ready list with a wait and a callback on one epoll take disjoint slices rather than each seeing private or overlapping copies.

Minor semantic divergences to note:

• epoll_pwait ignores sigmask
• epoll_create1 ignores EPOLL_CLOEXEC
• nesting is capped at 5 levels
• epoll_event under Wasm in Musl is laid out as aligned 16 rather than x86-64's packed 12 bytes.

PR made with AI assistance, under my review

[sbc100]

I think this like this direction.

I've not had time to look at all the details yet, but it seems like a great idea to unify the node events like this.