^C in gdb ignored when doing reverse-execution of a replay with conditional-bp

I was trying to debug a replay, and I set up a conditional bp and did a reverse-continue. It took longer than I was expecting, so I tried to ^C to interrupt and get back to a debug prompt. rr ignored the ^C and I had to resort to killing the whole debug session and restarting it.

(rr) cond 9 (itb->pc - 0xffffadea4000) == 9e6924
(rr) rc
Continuing.
^C
^CInterrupted while waiting for the program.
Give up waiting? (y or n) n
^C^CInterrupted while waiting for the program.
Give up waiting? (y or n) y
Quit

The bp condition was of a form that meant it couldn't be executed on the rr end ('info bp' said "host evals"), so slowness is perhaps expected, but the user should always be able to regain control with ^C.

(This is with rr commit b8821907e0ed.)

Reproduce the issue with a reverse-continue and a conditional breakpoint whose condition is evaluated by the host, then observe how rr handles repeated ^C input while waiting. Trace the interrupt-handling path for reverse execution and verify that ^C reliably returns to the debug prompt without requiring the session to be killed.