RFC: io and os reform

This RFC proposes a significant redesign of the `std::io` and `std::os` modules
in preparation for API stabilization. The specific problems addressed by the
redesign are given in the Problems section below, and the key ideas of the
design are given in Vision for IO.

[Rendered](https://github.com/aturon/rfcs/blob/io-os-reform/text/0000-io-os-reform.md)
> As I explained the unsatisfactory portion is the reliance on _pipe.

There is no reliance on `_pipe`. The `_pipe` function calls into `CreatePipe`.

> By switching to using CreatePipe we may discover a set of functionality that windows supports that unix doesn't which means we'll want some extension traits. 

There is nothing to "discover". The `_pipe` function is a thin wrapper around `CreatePipe`. The `CreatePipe` function provides support for anonymous pipes. It is known to be portable functionality.

> Considering these APIs can happen at a later date, however, and we can migrate the implementation to std::io once implemented (it shouldn't be too hard!).

It is already implemented in a portable way. You don't want it to call the wrapper function in the CRT, so you easily change the implementation to call `CreatePipe` directly instead of regressing the functionality and leaving behind pointless legacy APIs in platform-specific modules.

> Our goal is to gradually cease reliance on msvcrt over time, not necessarily overnight. By not stabilizing the windows implementations of std::io which use it we're taking a step forward, but I'm sure there are plenty more!

Removing portable APIs is not taking a step forwards. It is not eliminating a reliable on the CRT either, because the functionality is available without the CRT. I don't know why this is so hard to understand.