Socket select and poll restart finite timeouts after every signal interruption #217

Finite socket waits restart their entire timeout after every EINTR. A stream of otherwise harmless signals can therefore keep an event loop blocked well past its requested deadline, potentially indefinitely while signals continue.

Regression coverage first: test/regression/SocketInterruptedDeadline in the existing Main.hx/build.hxml/stdout.txt layout. Install an isolated SIGALRM handler and deliver a signal every 10 ms for 30 ticks. Ask select, fast_select and poll_events to wait 50 ms with no ready descriptors. Restore the old signal action and timer afterwards. The signal source stops itself, and the test is also run under an external watchdog.

Confirmed on Linux x86_64 with Haxe 4.3.3:

select kept deadline: false
fast_select kept deadline: false
poll kept deadline: false

The test allows 200 ms for the 50 ms timeout. All three calls exceed that allowance while the signals continue, instead of completing near the original deadline.

In src/hx/libs/std/Socket.cpp, socket_select and socket_fast_select jump back above init_timeval after EINTR, restoring the original interval. socket_poll_events retries poll with the original timeout * 1000 every time. Retrying the interrupted operation is correct, but restarting its deadline is not.

Compute a monotonic deadline once for a finite wait and pass only the remaining interval after interruption. Rebuild select's descriptor sets on every attempt, handle rounding at expiry, and preserve the intended infinite-wait behavior. Test continuous signals and a socket becoming ready before the deadline as additional cases.

This is distinct from the clock-source issue for thread waits in #12. These socket waits use relative OS waits but extend their duration on each retry. No runtime implementation changes are included.