HANG while running gcc with sample cbr: synchall fails to handle vfork properly

**Describe the bug**
When running `gcc hello.c -o hello` with the client `cbr`, dynamorio hangs. This was observed for both x86 and RISCV64.

However, when we do not use `dr_flush_region()` and `dr_redirect_execution()` in [cbr.c](https://github.com/DynamoRIO/dynamorio/blob/304faf96845b06b4889e1c2ce1b49c3ba9b22462/api/samples/cbr.c#L265), everything is OK! As we have inserted the `jmp` instruction after clean call, cbr still works correctly without `dr_flush_region()` and `dr_redirect_execution()` (with performance loss perhaps).

So, dr_redirect_execution() may involves some bugs. As we invoke `prepare_for_call_ex()` and other 'save' operations before clean call, I'm not sure it's right not to call `cleanup_after_call_ex()` to restore when using the dr_redirect_execution() routine.

X86 output log is:

```
$ ./bin64/drrun -c api/bin/libcbr.so -- gcc ../scripts/test_clients/hello.c -o ../scripts/test_clients/hello_x86

...... (repeating)
```

**Expected behavior**
DO NOT use dr_redirect_execution() in cbr, we can run the program successfully:

```
$ ./bin64/drrun -c api/bin/libcbr.so -- gcc ../scripts/test_clients/hello.c -o ../scripts/test_clients/hello_x86

<-- execve /usr/lib/gcc/x86_64-linux-gnu/9/cc1 -->

<(1+x) Handling our fault in a TRY at 0x00007fecc87f4d4e>

<-- execve /home/chy/.local/bin/as -->
<-- execve /usr/local/sbin/as -->
<-- execve /usr/local/bin/as -->
<-- execve /usr/sbin/as -->
<-- execve /usr/bin/as -->

<(1+x) Handling our fault in a TRY at 0x00007f2064b7ed4e>

<-- execve /usr/lib/gcc/x86_64-linux-gnu/9/collect2 -->

<-- execve /usr/bin/ld -->

<(1+x) Handling our fault in a TRY at 0x00007f0309de9d4e>

```

**Other information**

- Without any clients, everything is OK.
- Under my test, some simple applications (such as `hello_world.c`, `ls` and so on) can run correctly.
- cbr sample has not been ported to AARCH64 formally, but I have tried it and found that it still faces the same problem of dr_redirect_execution().

Start at api/samples/cbr.c around the dr_flush_region() and dr_redirect_execution() calls near line 265, then reproduce the hang with cbr running gcc hello.c -o hello. Compare this with the variant that omits those calls and inspect the synchall/vfork handling involved. Done means gcc completes without hanging on the reported x86 and RISCV64 cases.

Written by the indexing model from the issue text.