behaviour then only running thread exits (non-stop mode)

[Doug Evans <dje at google dot com>]

What's the intended behaviour, as far as what the user sees, when the
only running thread exits in non-stop mode?
[where this thread is not the main thread, and there can be any number
of other threads, they're just not running - e.g. the user is
singlestepping one thread in non-stop mode]

Currently gdb is hanging because thread exits are ignored (in the
TARGET_WAITKIND_IGNORE sense), and with no thread running even ^c's
passed to the target (via pass_signal) won't get the command prompt
back.

Non-stop mode is not supposed to automagically switch threads on the
user, so it seems like gdb shouldn't randomly switch to another
thread.
I'm blocked on deciding how to break out of the event loop so that the
user can at least get the command prompt back. Throwing an error in
linux_nat_filter_event (which is where this situation is first
detected) feels wrong but maybe it's ok.