Fix quickjs-libc signal handling race

[bnoordhuis]

quickjs/quickjs-libc.c

Line 172 in 62f4713

static uint64_t os_pending_signals;

And then:

quickjs/quickjs-libc.c

Lines 2019 to 2022 in 62f4713

	static void os_signal_handler(int sig_num)
	{
	os_pending_signals |= ((uint64_t)1 << sig_num);
	}

And lest we forget:

quickjs/quickjs-libc.c

Lines 2408 to 2410 in 62f4713

	mask = (uint64_t)1 << sh->sig_num;
	if (os_pending_signals & mask) {
	os_pending_signals &= ~mask;

Problems:

1. os_pending_signals is not volatile

2. os_pending_signals is not _Atomic

3. Signals get lost when event loop A "steals" them from event loop B

4. The signal handler is installed with signal(2), not sigaction(2), resulting in different behavior depending on how quickjs-libc.c is compiled, at least on Linux. From man 2 signal:

The kernel's signal() system call provides System V semantics.

By default, in glibc 2 and later, the signal() wrapper function does not invoke the kernel system call. Instead, it calls sigaction(2) using flags that supply BSD semantics. This default behavior is provided as long as a suitable feature test macro is defined: _BSD_SOURCE on glibc 2.19 and earlier or _DEFAULT_SOURCE in glibc 2.19 and later. (By default, these macros are defined; see feature_test_macros(7) for details.) If such a feature test macro is not defined, then signal() provides System V semantics.

SysV semantics = handlers are re-entrant (SA_NODEFER); worse, handlers are one-shot - they are removed on delivery of a signal.