Fix 409141 and 409367: valgrind hangs or loops when a process sends a signal to itself.

Fix 409141 and 409367: valgrind hangs or loops when a process sends a signal to itself.

The loop scenario:
  The main thread sends a signal 15 to another thread, and then calls the exit syscall.
  The exit syscall done by thread 1 marks all threads as needing
  to die using exitreason VgSrc_ExitProcess.
  The main thread then gets all other threads out of their blocking syscall
  to let them die, and then "busy polls" for all other threads to disappear.
  However, when the second thread is out of its syscall, it gets the signal 15,
  which is a fatal signal.  This second thread then changes the exit reason
  of all threads to VgSrc_FatalSig, and itself starts to busy poll for all
  other threads to disappear.
  This then loops forever.

  The fix for this consists in not handling the fatal signal in the
  second thread when the process is already busy dying.  Effectively,
  the exit syscall should be processed "atomically": either the process
  is running, or it is dead once the syscall is done.
  Under valgrind, when threads are marked as being ' VgSrc_ExitProcess',
  the guest process should be considered as dead.  Valgrind has still to do
  the cleanup, the endof run report, etc  but otherwise should not let
  any more user code to run.  So, signal should not be handled anymore
  once the 'exit syscall' has marked all threads as VgSrc_ExitProcess.

The hang scenario:
  The main thread sends a signal 9 (KILL) to itself.
  When running natively, this directly kills the process,
  without giving any opportunity to run some user code.
  Valgrind intercepts the kill syscall, and detects that this is
  a fatal signal.  The main thread was then dying, but was
  not getting the other threads out of their syscall (to let them die).

  The fix for this is to have the 'handling' of the signal 9 sent to a
  thread of the process to directly make the process die, by getting
  all threads out of syscall.
  Note that the previous code was trying to have this action done by
  the thread to which the signal 9 was sent.  This was too tricky to
  keep (causing other race conditions between the main thread sending
  the signal 9 e.g. exiting and the other thread supposed to die).
  As it is not particularly critical to have the signal 9 'handled'
  by a specific thread, the thread that is sending the signal 9 is
  the one doing the work to cleanup and terminate the process.