When a task threw (normal exception) or crashed (IllegalInstruction), the
worker signalled the future twice: first PHP_PARALLEL_ERROR (or READY|ERROR),
then an unconditional trailing PHP_PARALLEL_READY at the end of
php_parallel_scheduler_run().

Future::value() waits on READY|FAILURE|ERROR, so the first signal already
releases the consumer. The consumer can then tear the future down (freeing
future->monitor) before the worker runs the trailing
php_parallel_monitor_set(future->monitor, PHP_PARALLEL_READY), which then
dereferences a dangling monitor inside pthread_cond_signal -> access
violation / use-after-free.

This was observed as a hard crash on Windows (0xC0000005) in
tests/functional/007.phpt, masked until now by the catch-all VEH; on Linux
the freed memory happened to stay readable.

Fix: the error paths now signal READY|ERROR exactly once and skip the
trailing READY (via a 'ready' flag). The success and kill paths are
unchanged - they have no early wake and still rely on the trailing READY.
Setting READY in the error path also ensures the future destructor (which
waits for READY) never blocks when value() is not called.

Apply the same policy the POSIX SIGSEGV handler already has (#378) to the
Windows vectored exception handler: only convert an access violation into a
catchable IllegalInstruction error when a parallel worker faulted on a call
to a function missing from its function table. Every other access violation
is forwarded to the previously installed handler via EXCEPTION_CONTINUE_SEARCH
(and crashes cleanly if nothing handles it) instead of being masked by an
unconditional zend_bailout().

The missing-function detection is shared between both handlers via
php_parallel_scheduler_recover_missing_function().