Signal handling

Originally filed at https://github.com/rust-lang/rust/issues/11203

This involves filling out libnative/io/mod.rs, but this is also a very tricky issue. Right now the API is wrapped around what libuv provided for us, but that may not be the best API to have.

Dealing with signals is always an incredibly tricky topic, and here's the ideas for what should possibly happen:

• on linux (maybe android?) signalfd should be used for everything
• on windows, basically just do whatever libuv does and pray that everything works
• on everything else, we're going to have to resort to sigaction. I believe that the best way to deal with this is libuv's trick of a self-looping pipe (the signal handler writes the signal onto a pipe which is read in the "event loop"). This will certainly involve some trickiness.

It has also been brought up that there are primitives like sigwait on unixes which can be used to just block a thread when waiting for "some group of signals", but the API which we have created for signals cannot wrap this functionality. We could add a similar function for libgreen/libnative, but I personally don't think it's worth it. It is worth some discussion, however.

Start with libnative/io/mod.rs and the original issue linked in the description. Review the existing libuv-wrapped signal API and compare the proposed signalfd, Windows/libuv, sigaction, self-looping pipe, and sigwait approaches. Done requires a resolved API and a signal-handling design that accounts for the stated platform differences.