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)
> Why can't we simply use Vec<u16> on Windows?

This was brought up in pre-RFC discussions. I think it’s fair to list it list it as an alternative.

We can, but then we can’t have `OsStr::as_str(&self) -> Option<&str>` returning a slice of existing memory: the conversion to Rust strings, even of the borrowed `OsStr` slice, would have to allocate and return an owned or `Cow` buffer.

So it’s trading cost in one place for cost in another. Maybe it’s worth it, I really don’t know.

> So the only benefit of `Wtf8Buf` is that English speakers who only use ASCII range of Unicode have a good chance of saving a little bit of memory.
> ```
> $ echo $LANG
> ja_JP.UTF-8
> $ echo -n こんにちは、世界 | wc -c
> 24
> $ echo -n こんにちは、世界 | iconv -f utf-8 -t utf-16 | wc -c
> 18
> ```

Using WTF-8 is not about saving memory. It’s about cheaper conversions (without re-allocating) to Rust’s standard string types `str` and `String`, and back. You most likely need to convert when doing anything with an OS string other than using it in another OS call. And it’s about having 

> On the other hand, every operation on `Wtf8Buf` is much more expensive than that on `Vec<u16>`; see `next_surrogate()` and `code_point_range_at()` for example.

FUD. `next_surrogate()` is only using during WTF-8 to UTF-8 conversions, which are O(n), like conversions from UTF-16. `code_point_range_at()` on WTF-8 or UTF-8 is non-trivial but still O(1), exactly like on UTF-16 (which is variable-width too).

To clarify: I think it’s fine for the internal representation of OS strings on Windows to be UTF-16, if we want to make different tradeoffs in terms of where conversions happen. I’ll write up a proposal of what the API could look like. But the reasons you give are not the right ones.