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)
> The movement of datasync is reflecting that the purpose of the function (flush everything but metadata) is not currently implemented on windows. In this sense we can provide a lossy cross platform abstraction (just use the normal sync on windows), but it's not necessarily what you were asking for. Cases like this are pretty borderline though, and could go one way or the other.

You've obviously ignored my points in the discussion because you're continuing to spread misinformation. The claim that it is a lossy platform abstraction is completely false. There is nothing lossy about an implementation in terms of `fsync`. Per the documentation, it may be (and often is) implemented in the same way as `fsync` or even `syncfs`. There are many filesystems on *nix where it is the same operation. It is *intended* to be that way.

> APIs like unix domain sockets/named pipes (currently std::io::net::pipe) are being moved because the underlying models are fairly radically different and we would like to take some time to invest in developing the underlying os-specific abstraction before creating a cross-platform abstraction. The current API of abstracting across the two with a unix-domain-socket-like API is a relic of using libuv (it's what they did), and may not be the API that we'd like to stabilize on. In general it seemed like a port of std::io that was a clear candidate for moving into os::platform and evolving into std::net at a later date.

Not relevant.

> Functionality like io::pipe has been moved into os::platform because the windows implementation relies on _pipe which is not something we are willing to commit to. Over time we can develop a cross-platform abstraction and then promote these apis back to `std::io.

The `_pipe` function calls `CreatePipe` and if your problem with it is that it's using the CRT it could be switched over. I don't see you asking for liballoc to be removed because it calls `malloc` instead of `HeapAlloc`. There are *many* calls into the CRT in the Rust standard libraries. They can be eliminated without removing functionality when it's just an implementation detail. I don't understand this reasoning at all.