test_signal: Signal handling on the Tru64 buildbot

appears to be utterly insane.  Plug some theoretical
insecurities in the test script:

- Verify that the SIGALRM handler was actually installed.

- Don't call alarm() before the handler is installed.

- Move everything that can fail inside the try/finally,
  so the test cleans up after itself more often.

- Try sending all the expected signals in
  force_test_exit(), not just SIGALRM.  Since that was
  fixed to actually send SIGALRM (instead of invisibly
  dying with an AttributeError), we've seen that sending
  SIGALRM alone does not stop this from hanging.

- Move the "kill the child" business into the finally
  clause, so the child doesn't survive test failure
  to send SIGALRM to other tests later (there are also
  baffling SIGALRM-related failures in test_socket).

- Cancel the alarm in the finally clause -- if the
  test dies early, we again don't want SIGALRM showing
  up to confuse a later test.

Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.

test_threadedsignals:  curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM.  Anyway,
fixed an obvious (but probably inconsequential) logic
error.

Lib/test/test_threadsignals.py

@@ -49,7 +49,7 @@ class ThreadSignals(unittest.TestCase):
         # and might be out of order.)  If we haven't seen
         # the signals yet, send yet another signal and
         # wait for it return.
-        if signal_blackboard[signal.SIGUSR2]['tripped'] == 0 \
+        if signal_blackboard[signal.SIGUSR1]['tripped'] == 0 \
            or signal_blackboard[signal.SIGUSR2]['tripped'] == 0:
             signal.alarm(1)
             signal.pause()