Signal arriving between pre-syscall event and syscall can cause problems for clients

Realized while discussing an asynchronous signal arriving after we emit the
syscall marker for drmemtrace in the pre-syscall event handler but before
the syscall starts, for PR #6096.

DR does ignore pending signals for what it considers "ignorable" system
calls, which do not block:

```
/* It is difficult to undo some pre-syscall handling, especially for
* sigreturn's signal mask and clone syscalls. We go ahead and run the
* syscall before we deliver the signal for all non-ignorable syscalls.
* These are nearly all non-blocking so this should not be an issue with
* signal delay from blocking. Sigreturn and clone will come back to
* d_r_dispatch so there's no worry about unbounded delay.
*/
```

So for other system calls, DR will call client pre-syscall event handlers
but then go run the app's signal handler and once that's done it will go
back to the syscall: and repeat the syscall instruction (in a
tail-duplicated block) and repeat the pre-syscall event handler calls.

You can imagine the client taking some action that assumes no further code
will be run in that thread before the syscall. E.g., enabling PT tracing
in drmemtrace, or keeping some state that is fragile or assumes recency or
assumes a post-syscall event and would have a problem with an app handler
running (and maybe making the same syscall).

Could we consider all client-filtered syscalls to also be "non-ignorable"
and delay a signal? If the syscall is blocking this seems bad.

The best solution would be to pretend the signal arrived later: emulate the
kernel's interruption and set up for post-syscall handling with EINTR (plus
adjust PC for auto-restart) and deliver the signal. Afterward, make sure
we run the post-syscall event handler with the EINTR and return EINTR to
the app.

We could also check for pending signals right before the pre_syscall
handler to shrink the problematic window.

Start by reading the pre-syscall event handling and signal-delivery paths, using the drmemtrace context and PR #6096 as entry points. Trace how a signal between the syscall marker and syscall affects pre-syscall, post-syscall, EINTR, and restart behavior; done means client callbacks remain consistent in that window.

Written by the indexing model from the issue text.