i#1921 native sig: Handle signals during DR initialization

[derekbruening]

Puts in place 6 fixes for handling signals during DR initialization,
typically in a start/stop setup where other threads are alive.

1. Copy the app handler at init time for delivering native signals
   during init.

2. Reorder signal_arch_init(), which obtains the signal frame size, to
   run before DR installs its handler.

3. Obtains the app handler before installing DR's handler, eliminating
   a (narrow) race window.

4. Until DR starts executing the app, continues delivering native
   signals and using the globally recorded app handler, to match how DR
   init works.

5. Set detacher_tid between init and setup to avoid races like in
   DR's handler at the end of init that were under safe_read magic unstable during detach from threaded app. #3535

6. Handle a race where the init thread has set the global try_except,
   causing master_signal_handler_C to think an app thread's signal is
   DR's. We add a global_try_tid and check the thread id to solve this.

Augments api.detach_signal with signals sent during init.

Also tested on a large proprietary application.

Issue: #1921, #3535

[derekbruening]

Hmm, detach_signal failed on 32-bit x86 with no output. But locally 32-bit x86 succeeds 100x in a row.

[derekbruening]

Hmm, detach_signal failed on 32-bit x86 with no output. But locally 32-bit x86 succeeds 100x in a row.

Finally reproduced it in an Ubuntu 16.04.7 LTS VM, and after a lot of debugging (very confusing as to what happened initially), finally figured it out: it's the vsyscall hook not handling native threads in general. So it is not a regression of any kind: it's just that my expanded test here hits that always-broken case. I filed #4664 for that and for now in this PR I'm going to make the test 64-bit only.