stack trace with python 3.7 when exiting client with `^C`

Summary

When using ^C to terminate all jobs and quit immediately, I am now seeing this new stack trace. [//]: # (Summarize the bug encountered concisely)

Steps to reproduce

Launch a build and interrupt it with ^C

User interrupted with ^C

Choose one of the following options:
  (c)ontinue  - Continue queueing jobs as much as possible
  (q)uit      - Exit after all ongoing jobs complete
  (t)erminate - Terminate any ongoing jobs and exit

Pressing ^C again will terminate jobs and exit

Choice: [continue]:

Waiting for input... so far so good, now hit ^C again:

Choice: [continue]:^CException in callback Scheduler._interrupt_event()
handle: <Handle Scheduler._interrupt_event()>
KeyboardInterrupt

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.7/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/codethink/GNOME/buildstream/buildstream/_scheduler/scheduler.py", line 475, in _interrupt_event
    self._interrupt_callback()
  File "/codethink/GNOME/buildstream/buildstream/_frontend/app.py", line 506, in _interrupt_handler
    default='continue', err=True)
  File "/home/tristan/.local/lib/python3.7/site-packages/click/termui.py", line 116, in prompt
    value = prompt_func(prompt)
  File "/home/tristan/.local/lib/python3.7/site-packages/click/termui.py", line 100, in prompt_func
    return f('')
SystemError: PyEval_EvalFrameEx returned a result with an error set

Oops, ugly stack trace, and we still didnt quit... now we're hanging... hit ^C one more time:

^C
Aborted!

Now we're done, but we never actually even terminate ongoing jobs, we've just brutally interrupted and exited the main process.

What is the current bug behavior?

Stack traces.

What is the expected correct behavior?

Cleanly handle the ^C interrupt as intended and terminate jobs and then exit.