Add signal handlers on Unix systems to catch simple crashes about deepstate HOT 4 CLOSED

I started an implementation of this, then realized that there's a problem. If you longjmp/siglongjmp from a signal handler and go on to call any non-async-signal-safe function, the result is undefined behavior. From end of signal-safety(7):

   *  If a signal handler interrupts the execution of an unsafe
      function, and the handler terminates via a call to longjmp(3) or
      siglongjmp(3) and the program subsequently calls an unsafe
      function, then the behavior of the program is undefined. 

For us, the biggest problem is that the signal we want to handle could have interrupted some (in general) async-unsafe code under test. So, if we trapped a signal from the test code, called DeepState_Fail(), and thus non-locally jumped back to the main loop of DeepState_Run(), it might corrupt some global/static state which would impact subsequent test runs. We can't get around this just by e.g. narrowly scoping when we trap the signal, trying to make all our harness code async-safe, &c.

A few options:

1. Don't support catching signals for now.
2. Do it anyway, perhaps making this demon-plagued behavior configurable via a flag.
3. Fork when executing test functions with the native harness, gather results using IPC.

Option (3) probably requires some big cross-cutting changes, and might have some gotchas with respect to the executors (though we could just not fork when being run by an executor). I think (2) will lead to grief later on down the line, so I'd suggest putting this issue on hold until we can address it via (3).

from deepstate.

What about a variant of options (2) and (3). If a flag is not set, then the signal handler, upon catching the signal, prints out that the option isn't set and then promptly exits. If the flag is set, then we fork for each test, and the parent process uses waitpid, WIFSIGNALED, and WTERMSIG to check if the child was signalled.

from deepstate.

@pgoodman, I think we can close this, as it should be subsumed by the move to forking test runs in #29.

That work does not introduce any signal handler-based hooks or options, but I think that to it would be better to avoid them unless we have a really compelling use case that can't be addressed with the process-oriented test running.

from deepstate.

Sounds good :-)

from deepstate.