event: support pipe sources on Windows

This implements full support for using pipe sources on Windows to
trigger an event when a pipe becomes readable or writable.

Due to differences between the Windows asynchronous I/O model and the
Unix model, this is rather complex. On Windows, the standard mechanism
to achieve asynchronous pipe I/O is to just read or write from the pipe
and then get notified once the operation completes. Unlike the Unix
`select()`/`poll()` model, there is no way to simply know when a pipe
becomes readable or writable without actually running an operation. So
we need to resort to several tricks in order to achieve the semantics
that Dispatch wants here.

To monitor a pipe for readability, we take advantage of the fact that a
zero-byte `ReadFile()` on a pipe will block until data becomes available
in the pipe. A muxnote which monitors a pipe for reading will spin up a
lightweight thread which repeatedly calls `ReadFile()` (blocking) on the
pipe and posts back to the I/O completion queue when it returns.

To monitor pipes for writability, we use the `NtQueryInformationFile()`
kernel API to get the amount of available space in the pipe's write
buffer. There is no way to block here, so we have no choice but to
continually disarm and rearm unotes until space becomes available. This
is inefficient, but it generally seems to work OK.

In order to test this, I implemented a new dispatch_io_pipe test which
performs various read and write operations on pipes. On Windows, this
will run the tests on most of the different pipe kinds (anonymous,
named, inbound, outbound, overlapped). This caught a lot of issues in
the Windows `_dispatch_operation_perform()` which I fixed along the way.
The dispatch_io and dispatch_io_pipe_close tests pass as well with my
other pull request applied.

Author: adierking