support for windows named pipes

The subprocess PR (#791) added the core functionality to work with Windows named pipes, but only exposing in them in the limited case of talking to subprocesses. People may also want to use named pipes directly in some cases; they're kind of like windows's equivalent to AF_UNIX. (Well, except now AF_UNIX sockets are the equivalent to AF_UNIX sockets, but only on recent versions of Windows 10, so that won't be universally available for some time yet.) Perhaps we should have client and server helpers.

I was going to try to cite an example of a case where you have to use named pipes to connect to some program, but the only example I know is Discord and apparently they're using localhost sockets now? I know they used to, but I can't find any docs that mention named pipes anymore. So perhaps this is not a great argument for named pipe support being important.

There is also some question to figure out about how much of the named pipe API to expose – the full thing is somewhat complicated, with unidirectional/bidirectional streams, bytes vs. packets, peekable reads, etc., but I suppose just exposing a regular Stream-based APi would be a reasonable start

Start by reviewing subprocess PR #791 to understand the existing Windows named-pipe functionality. Determine the intended scope of direct client and server helpers and whether a regular Stream-based API is sufficient, then define completion around usable direct named-pipe support beyond subprocess communication.