We have a rudimentary stall detector that triggers if a queue doesn't
yield within 5ms of being scheduled for execution. Using the preempt
timer duration instead will limit the false positives we log (if the
user specify a preempt timer of 100ms then they are fine with a task
queue running for that much time.)

Knowing if a queue is stalling the reactor is nice, but finding the
exact code location where the stall occurs remains very hard. Especially
if a task queue hosts many concurrent fibers.

To help with that, this commit introduces a stall detection mechanism
that records stack traces of stalling tasks. It works as
follows:
* When a task queue is scheduled for execution, we set up a timer that
triggers some time after the queue is expected to yield (we add a 10%
error margin to avoid false positives). A background thread collocated
with the local executor waits on the timer at all times.
* When the timer fires, the thread sends a signal (SIGUSR1) to the local
executor thread. Upon receiving the signal, the local executor records a
complete trace of the local stack. Here we take advantage of the fact
that by default, the kernel invokes signal handlers on top of the
existing stack. i.e. the frames we record are those of the problematic
user code that was meant to yield. The recorded frames are pushed on a
non-blocking communication channel that links the signal handler and the
local executor.
* When a task queue yields, the local executor disarm the timer and
checks the communication channel for potential recorded frames, if there
are any then we can conclude that the queue stalled, so we log them.

This code works in practice but has two major drawbacks:
* The timer dance is expensive; expect a high number of syscall. Because
of this runtime overhead, the stall detector is disabled by default. To
opt-in, the feature `stall-detection` must be enabled at compile-time.
* We log stalls only after the queue yield. Therefore, if there is a bug
in your code and your queue never yields, the stall detector will never
log the code location that's at fault (even though we probably have
recorded the trace by then). The reason for this is that logging from a
signal handler is illegal.

and trace collection eventually.

for checking that incoming signals match expected executor.

by moving signal_id from `LocalExecutor`.

and make all knobs configurable.

need to write tests to validate enabling/disabling at runtime.