Replace the signal handling system

[SeanTAllen]

The old signal system's problems were design-level, not bugs to patch around. Registering two handlers for the same signal did different things on different platforms: on Linux the first silently won and the loser hung forever waiting for notifications that never came (#5130); on macOS the second silently replaced the first. Signal handling was the one I/O primitive in the standard library with no capability gate. Registration accepted fatal signals that cannot be meaningfully handled, uncatchable ones the OS silently refused, and SIGUSR2, which the runtime reserves for scheduler wake — all without error, and a handler for the last two never fired. A registration that failed was indistinguishable from ordinary disposal, and its error path left the OS handler installed with nothing behind it (#5128); on the delivery side, a failed read sent a signal count from uninitialized memory (#5152). A signal arriving during runtime shutdown could touch freed memory (#5564).

This replaces the system, implementing RFC #87. Registration is gated by SignalAuth and takes only validated signal numbers (HandleableSignal). A signal fans out to up to 16 subscribers, the same way on every platform, and registration commits synchronously so a raise right after subscribing cannot be lost. Failures are reported through SignalNotify.registration_failed, and the handler whose registration failed disposes itself. The notify's disposed callback fires when unregistration has actually finished. Shutdown restores default dispositions instead of leaving the process pointing into freed runtime state.

User-facing details and migration examples are in the release note (.release-notes/replace-signal-handling.md). The Windows port targets the readiness backend that replaced IOCP on main (#5556), and main's silent-failure hardening in the ASIO backends carries through the redesigned signal paths.

Closes #5793
Closes #5152
Closes #5128
Closes #5130
Closes #5564

[ponylang-main]

Hi @SeanTAllen,

The changelog - changed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4984.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.