Support cooked input cancellation on Windows

[alexrp]

See discussion on #46 and #61, as well as commit adf2a45.

[alexrp]

Started a discussion: microsoft/terminal#12143

[alexrp]

Proposed a whacky but potentially workable(?) hack for this here: microsoft/terminal#12143 (comment)

Thoughts on that approach very welcome. (cc @scottbilas @xoofx)

[scottbilas]

I'm always in favor of an approach that works, even with caveats, over endless waiting for the gears to turn in a big software company. :) Seems like it's hard to get their attention on this.

[alexrp]

One aspect to consider is how this would work when standard I/O handles are redirected. Obviously, if we close redirected handles, we can't just simply reopen them again like we can with the console. We would need to special-case files, pipes, etc.

🤔

Looking at the .NET BCL, there's a whole bunch of code to handle cancellation in the FileStream backend code, both for the synchronous and asynchronous cases. So I'm now thinking this should be tied into #76 so we can make use of all the infrastructure that the .NET BCL already has in place for handling synchronous/asynchronous cancellation for those cases. Due to the Unix issue mentioned there, we could just do this work in the Windows terminal driver only, for now. (That's fine anyway, as the Unix terminal driver is quite clean in general, and UnixCancellationPipe has served us pretty well.)

[alexrp]

Sigh. Doesn't seem like that hack will work either.

• Reading from GetStdHandle(STD_INPUT_HANDLE) and then closing that handle from another thread doesn't cause the read to get interrupted for some reason.
• Reading from CreateFile("CONIN$", ...) and then closing that handle from another thread just causes CloseHandle() to block until the read completes.

I guess this might have worked on Windows 7, but Windows 8.1 completely changed how console handles work, so I figure that's why I had no luck here.

Sadness all around.