gdb has poor support for DR's new takeover signal SIGSTKFLT

For #5458 (closed) we switched from SIGUSR2 to SIGSTKFLT. However, gdb does not handle this signal well at all:

Thread 2 "tool.drcacheoff" received signal ?, Unknown signal.
(gdb) p $_siginfo
$1 = {
  si_signo = 16,
(gdb) c
Continuing.
warning: Signal ? does not exist on this system.

(gdb) handle 16 nostop noprint pass
Only signals 1-15 are valid as numeric signals.
Use "info signals" for a list of symbolic signals.
(gdb) handle SIGSTKFLT nostop noprint pass
Unrecognized or ambiguous flag word: "SIGSTKFLT".

I tried handle all nostop noprint pass and it didn't apply to signal 16! So we have to hit c a hundred times to make progress which is not good.

I saw this in gdb version 9 and 10.

I propose we switch to SIGPWR which gdb does support. I tested it with gdb and with QEMU and QEMU does not freak out and abort like it does with SIGFPE.

Other candidates are SIGXCPU and SIGXFSZ but the kernel will produce those: SIGPWR seems more obscure.