i#1921 native sig: Deliver signals to unmanaged threads

[derekbruening]

When a signal arrives in an completely unmanaged thread with no
dcontext, typically because DR is detaching, we now deliver the signal
if the application has a handler for it. This requires adding support
for no dcontext to several parts of the frame setup code even beyond
what was added in PR #4603 for temporarily-native threads.

We have to save the app's handler when we detach a thread so we know
where to send a native signal. Full support is complex when we're
cleaning up and have no dynamic storage, so we use a single global
handler per signal. We detect whether multiple handlers are in
operation in this single DR instance (quite rare: only custom
non-pthread clones have this behavior) and in that case we abort like
before on a native signal. Adds ATOMIC_READ_1BYTE() to complement the
existing atomic operations for a cleaner read of the new multi-handler
flag.

Delivering the frame often overlaps with DR's frame and even DR's
stack usage while delivering, if the app has no sigaltstack. We add
logic to detect this overlap and avoid clobbering the stack memory.

Alarm signals are still dropped, since they can arrive mid-thread-init
when it is even harder to deliver.

Adds a new test api.detach_signal which creates 10 threads who all sit
in a loop sending 4 different alternating signals (SIGSEGV, SIGBUS,
SIGURG, SIGALRM) while the main thread attaches and then detaches.
When run in debug build, many many signals arrive in post-detach
threads, since detach takes a while to do debug cleanup, exercising
the new code.

Adds a new RSTAT for native signals so we can identify when this
happens in release build. Exports the stat to the API and uses it to
check that at least some signals were delivered natively in the new
test.

Removes the fatal error on a signal arriving with no dcontext. But,
non-ignore default signal actions when no handler is present are still
not fully handled, along with multi-sighand-processes as mentioned,
and the fatal error remains in those cases. For default actions,
since the process is going to terminate anyway, the only shortcoming
of this is whether a core is generated and whether the proper process
exit code is raised.

Issue: #1921

[derekbruening]

Test failures are minor, of two types: missing UNIX ifdefs for Windows; and an assert in the atomic macros that should look at the target.