Fixes #136

To summarize, the issue in #136 is that when dumb-init calls TIOCNOTTY, the kernel will send a SIGHUP and SIGCONT to the dumb-init process if dumb-init is the session leader. Quoth man tty:

    TIOCNOTTY
       Detach the calling process from its controlling terminal.

       If the process is the session leader, then SIGHUP and  SIGCONT  signals
       are  sent to the foreground process group and all processes in the cur‐
       rent session lose their controlling tty.

When this happens, there's a race with two possible outcomes:

1. (Happy path) dumb-init pid1 receives the SIGHUP/SIGCONT and forward them to the child (pid2), but the child hasn't yet exec'd the real process. The pid2 dumb-init just ignores the signals, eventually execs the real process, and nobody notices this quirk.
2. (Sad path) dumb-init pid2 has exec'd the real process by the time the pid1 dumb-init forwards it the SIGHUP/SIGCONT. The real process gets the SIGHUP and usually dies with status code 129 (killed by SIGHUP).

Typically (1) happens, but some environments cause (2) to happen more frequently, probably due to differences in how the scheduler behaves.

This is a fairly non-intrusive fix: it just ignores the first SIGHUP/SIGCONT. At some point I'd still like to see if there's a better fix (can we hand the session to the child when we're the session leader rather than creating a new one?), but this should be fairly safe.

Still working on writing a test. Unfortunately it's hard to test the actual functionality (hard to force the race without patching dumb-init's code) so it may end up just asserting debug messages :(