Fix signal handling test vs Ruby 1.9 async signals.

Ruby 1.9, unlike Ruby 1.8, uses a dedicated OS-level thread to handle signals.
This means that there can be arbitrary delays in signal delivery, thanks to
the vagaries of OS level thread scheduling.

The recent refactoring of application bootstrapping reduced the amount of OS
level activity in the self-signalling area, revealing this problem.

In the specific test, we used to have enough delay and OS interaction to
reliably (enough that I never saw the failure) switch to the signal thread and
run the code *before* we restored the previous signal handler.

After the changes we don't do that - that work is delayed, so the signal is
delivered during the test cleanup cycle, or even delayed until after the suite
exits.

This is, of course, not a problem on Ruby 1.8, where the signal is handled in
the main thread, and much more synchronously to the rest of the code.

So, the test is rewritten: we poll waiting for completion in the signal
handler, and have an outer timeout to catch a failure to invoke and fail out
of the test anyhow.

None of the native Ruby cross-thread communication or locking mechanisms
really satisfy the needs of this code, since we want to complete regardless of
when the condition is satisfied - even before we enter the wait period.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>