Add signal handling using sigaction(2)

Signals can have these actions:

    ign : SIG_IGN : the signal is ignored

    dfl : SIG_DFL : the signal action is set back to the default

    trap : N/A : an Erlang message is generated to the linked process

sigaction/2 is called as:

    alcove:sigaction(port(), [integer()], integer(), atom()) -> 'ok' | {'error', file:posix()}

    OSPid = 31423,
    Signal = alcove:signal_define(Port, hup),
    alcove:sigaction(Port, [OSPid], Signal, ign).

If the action is set to 'trap', the linked process will receive a
message with the format:

    {signal, integer(), integer()}

The signal handler is active until the calling process resets the
handler. The calling process should be capable of handling a stream of
signals firing. Multiple signals of the same type may be coalesced into
one event.

If the signal handler were set to fire once then require to be set
again, signals could be lost or the process accidentally killed.
According to the Linux signal(2) man page, this was the original
behaviour of signals on Unix systems:

    In  the  original UNIX systems, when a handler that was established
    using signal() was invoked by the delivery of a signal, the
    disposition of the signal would be reset to SIG_DFL, and the system
    did not block delivery of further instances of the signal.  System V
    also  provides these  semantics  for  signal().   This  was bad
    because the signal might be delivered again before the handler had
    a chance to reestablish itself.  Furthermore, rapid deliveries of
    the same signal could result in recursive invocations of the handler.

Some issues to fix:

* the test relies on a magic sleep so the child process has time to exit

* not so much a problem with this patch but signals (the signal message)
  will be returned to the erlang process in the next call. So doing:

    kill(Port, 1234, 15),
    kill(Port, 1234, 0),

  Can result in:

    {signal, 1234, 17} % child exited

  Instead of 'ok'.

  This is a problem with decoding messages which will be fixed later.

(The issue is each parent process adds a header to the message, ending
 up with a header of an arbitrary length. The Erlang process can't
 easily pattern match against these. Using an intermediary process,
 stdout from the port could be converted to:

    {cast, [1234, 12345], Data}
    {call, [], Data}
    {stdout, [1234], Data}
    {stderr, [1234,12345,12346], Data}

 And sent to the caller. This would be simple if aclove was a gen_server
 but the intent, so far, is that alcove is a simple library on which
 applications build gen_servers rather than adding more complexity and
 failure conditions inside alcove).