rseq sometimes-skipped fault cannot be accurately captured in a drmemtrace

Xref #5953, #5954. This is similar to #5953 where our instrumented run takes one side of a conditional branch, and the native run takes the other: but here instead of a jump exiting the rseq region a fault is generated (deliberately in our linux.rseq test).

This is what test_rseq_native_fault() in the linux.rseq test looks like today (before PR #5967 and before the forthcoming #4041 revert):
```
169107 128288: T1634859 ifetch 4 byte(s) @ 0x00007f3db11fac53 66 0f d4 c1 paddq %xmm1, %xmm0
169108 128289: T1634859 ifetch 5 byte(s) @ 0x00007f3db11fac57 66 48 0f 7e c0 movd %xmm0, %rax
169109 128290: T1634859 ifetch 4 byte(s) @ 0x00007f3db11fac5c 48 83 f8 02 cmp %rax, $0x02
169110 128291: T1634859 ifetch 2 byte(s) @ 0x00007f3db11fac60 75 02 jnz $0x00007f3db11fac64
169111 128292: T1634859 ifetch 1 byte(s) @ 0x00007f3db11fac64 90 nop
169112 128292: T1634859
169113 128292: T1634859
169114 128292: T1634859
169115 128293: T1634859 ifetch 1 byte(s) @ 0x00007f3db11fa878 55 push %rbp
169116 128293: T1634859 write 8 byte(s) @ 0x00007fff13fb1410 by PC 0x00007f3db11fa878
<...omitting most of signal handler...>
169137 128306: T1634859 ifetch 7 byte(s) @ 0x00007f3db4a87f90 48 c7 c0 0f 00 00 00 mov $0x0000000f, %rax
169138 128307: T1634859 ifetch 2 byte(s) @ 0x00007f3db4a87f97 0f 05 syscall
169139 128307: T1634859
169140 128307: T1634859
169141 128307: T1634859
169142 128307: T1634859
169143 128307: T1634859
169144 128308: T1634859 ifetch 2 byte(s) @ 0x00007f3db11fac6b eb 00 jmp $0x00007f3db11fac6d
169145 128309: T1634859 ifetch 4 byte(s) @ 0x00007f3db11fac6d 83 45 f4 01 addl $0x01, -0x0c(%rbp)
169146 128309: T1634859 read 4 byte(s) @ 0x00007fff13fb2124 by PC 0x00007f3db11fac6d
169147 128309: T1634859 write 4 byte(s) @ 0x00007fff13fb2124 by PC 0x00007f3db11fac6d
169148 128310: T1634859 ifetch 2 byte(s) @ 0x00007f3db11fac71 eb e0 jmp $0x00007f3db11fac53
169149 128311: T1634859 ifetch 4 byte(s) @ 0x00007f3db11fac53 66 0f d4 c1 paddq %xmm1, %xmm0
```

After PR #5967 it's similar except the nop (the committing "store") is rolled back.

This is not really what happened, and it doesn't even look like a synchronous fault with the nop or a store rolled back: it looks like an asynchronous signal; but that might behave differently in the app.

If the kernel would tell us the real faulting PC we could try to present it in the trace, but the rseq v2 in the mainline kernel provides no way to do that.