Implement epoll APIs in the JS filesystem

[guybedford]

Adds epoll_create1, epoll_ctl, epoll_wait and epoll_pwait on a single fd readiness model shared with poll().

Builds off of the existing event-driven readiness model in the JS FS system with the integration point as the per-inode wait-queue, having each FS node carrying a listeners set and producers calling 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): closing a watched fd and reusing its number for a different open does not resurrect the registration onto the new fd (matching Linux).
• dup(2) of an epoll fd yields another reference to the same epoll instance (registrations and ready list shared, per Linux eventpoll semantics); only the last close reclaims it.

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, dup instance sharing, JSPI and pthreads, real sockets, deregistration, deterministic round-robin fairness, and multi-threaded waits on a shared epoll fd (per-edge exactly-once wakeup under EPOLLET, herd wakeup under level triggering, and EPOLLONESHOT disarm/re-arm and exactly-once delivery against racing waiter threads).

Minor semantic divergences to note:

• epoll_pwait ignores sigmask
• epoll_create1 accepts and ignores EPOLL_CLOEXEC (unknown flags are rejected with EINVAL)
• closing a watched fd evicts its registration even when a dup of the open description survives; Linux keeps the registration alive through the file and continues delivering events (the classic epoll footgun)
• 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.

This PR originally also included emscripten_epoll_set_callback, a non-blocking JS-callback readiness variant (usable without ASYNCIFY/JSPI), which was split out into the follow-on PR #27547.

Fixes: #5033, #10556

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.

[sbc100]

I'm liking the direction of this commit but still a little overwhelmed by the size of it.

Can you think of any more ways to split it up? I'm not sure myself... for example, could we land the internal refactoring of the poll/select to use the new notification system before we land the rest of epoll? Maybe not practically separable?

[guybedford]

Can you think of any more ways to split it up? I'm not sure myself... for example, could we land the internal refactoring of the poll/select to use the new notification system before we land the rest of epoll? Maybe not practically separable?

I've refactored out the JS notification changes into #27226 if that helps?

[sbc100]

Is there some existing test for standalone.c where it verifies that it can at least link against all these symbol stubs? If not, we can add one, either as part of this PR or as a followup.

[guybedford]

Is there some existing test for standalone.c where it verifies that it can at least link against all these symbol stubs? If not, we can add one, either as part of this PR or as a followup.

other.test_standalone_syscalls is now extended to verify the syscalls.

[sbc100]

Looks like all the tests pass. ChangeLog.md needs a rebase, but I'll land without waiting for anther round of CI if you only change that.