We use a manual-reset event rather than an auto-reset event to cancel IO
on the pipe. This avoids unlucky cases where new IO would start just
after signalling the event and would block indefinitely while waiting on
the newly-unsignalled event.

As far as I can tell, if a read was cancelled from a background thread,
the IO operation wasn't cancelled, so the system was poking at the
stack-allocated OVERLAPPED structure after it had been removed from the
stack, at which point something else might be occupying that region of
stack memory.

I'm pretty sure Address Sanitizer should be able to catch this sort of
thing so I'm surprised it didn't complain here.

Previously, calls to `open` blocked when creating a writeable pipe.

This could cause other calls to block indefinitely, waiting for the pipe
to become available.

Now, we open the pipe in nonblocking mode, which allows us to retry
indefinitely, checking `stopReadOperation` each time to find out whether
`close` has been called and allowing a graceful exit.

The recent IFileChooser update to the JUCE FileChooser meant that
Windows build machines must be running Vista or newer.

For compilers other than MinGW, we were already requiring that the build
machine must be running Windows 8 or newer.