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.

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.

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.