Fix signal handling for Ruby 2 -- shutdown child processes

[evanbattaglia]

Ruby 2 complains when using Mutex#synchronize within in a trap context. This is because, if the program flow is interrupted by a signal while the program is in a synchronize block, and synchronize is called from the trap context, syncrhonize will never return because it will wait for the same process/thread to release the block.

Here, in a trap context, if we fail to get the lock, I add the signal to a signal queue which will be run soon after the synchronize block in the normal program flow is finished. If we can get the lock, we should shutdown / process the signal immediately, because main program flow is probably just waiting for the child process and so can not timely check the signal queue.

Addresses #202

I have checked to make sure the spec I wrote passes with my new code and does not pass with Ruby 2.1.5 using the old code. Some other qless specs are failing for me in all branches, including master, but it looks like Travis is OK.

@myronmarston @danlecocq @benkirzhner @tpickett66

[evanbattaglia]

there seems to be an intermittent spec failure in travis https://travis-ci.org/seomoz/qless/jobs/50413427 https://travis-ci.org/seomoz/qless/jobs/42763100

[evanbattaglia]

Myron suggested using a thread-safe queue, and Vadim pointed out that signals can arrive in the middle of an operation on @signal_queue¸ potentially leaving @signal_queue in a weird state. I will change @signal_queue to a rhread-safe queue (if Ruby lets me use it in a trap context)

[evanbattaglia]

@vadim-moz I updated this to use a Thread-safe queue. Test manually and behavior still looks OK, and my spec still passes

[evanbattaglia]

Cool looks good. I agree it's nicer just adding the block to the queue!