Translated stolen register app value lost on signal/synchall control transfer

[derekbruening]

When translating a thread context for synchall or on a signal, we invoke the client fault handler and arrive at the app's proper value for the stolen register in our local mcontext. We then use the same mcontext to get back into DR through an exit stub, but for that transition we need to put DR's TLS pointer back into the stolen register. That clobbers the translated value. If all client handlers did not touch the value, no harm is done since the TLS slot value is taken as the app value; but if a client were to need to restore a value there, we would get the wrong value in the end. This should be rare, since drreg avoids using the stolen register.

[derekbruening]

Taking this on as it is looking like it may be related to #4460 in that both seem to involve the TLS stolen reg slot across signals and translations.

[derekbruening]

For the signal path, it seems to only affect the handler itself: a longjmp out of there should restore properly to the setjmp value, and a re-execute will work since the sigcontext has the right value. It seems less likely that the handler will assume the value from the faulting context, but it is possible.

For the synchall path, this is a more serious issue and less of a corner case.