explicitly handle ctrl-c in confirmation prompt instead of signal handler

[ericmarkmartin]

Summary

Follow on to #11706. In the original PR, I tried to solve the issue by getting rid of the ctrlc::set_handler call. Unfortunately, this didn't work on windows due to an issue with the console crate. console 0.15.11 includes console-rs/console#235, which resolves the issue, so now we can get rid of the call.

This change is not super important but I still think it's worthwhile. For one, spinning up a background thread to handle SIGINTs when we're going to be raising the SIGINT from within the function is more technical complexity than needed, now that there's an easy way to explicitly catch the Ctrl-C from the terminal input. Secondly, ctrlc::set_handler's docs advise that you set the handler just once, at the beginning of the program, so this use seems somewhat error prone. In fact, uv already has a second callsite for this function (though I'm not sure if the two callsites could currently ever both occur on the same run of uv)

Test Plan

I've tested this manually on linux (WSL ubuntu) and windows, though not on aarch64-apple-darwin as I don't have a machine running that. I would appreciate if someone would double-check that it works on such machines.

As discussed in the original PR, this change is pretty hard to test due to the fact that the behavior only occurs if stderr is connected to a tty. I experimented with using pseudoterminals to test this but it's still quite tricky due to the lack of x-platform non-blocking reads on the pty.

[charliermarsh]

I can test it out on my MacBook real quick.