support for windows named pipes

[njsmith]

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

[njsmith]

One possible use case would be for setting up handles to talk to a child process, that aren't the standard 0, 1, 2 handles.

See #5 (comment)

[njsmith]

Well, here's evidence that at least one person does want to use these: https://stackoverflow.com/questions/61519940/async-named-pipes-in-windows-using-trio-and-python/