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)
> I dunno about a typical unix FS driver, but if we look at msvcrt implementation of chmod, it sets the read-only attribute = !S_IWUSR and ignores the rest of mode flags, returning 0 (i.e. "no error"). Actually, MS and MINGW headers don't even define the "group" and "other" mode flags, but since Rust's does not use bindgen, you'd never know that.

It wouldn't be calling the `_chmod` extension at all. The read-only bit is more comparable to `chattr +i` than POSIX permissions. It's portable because it has the same behaviour on \*nix and Windows...

> How about "a program creates a file, removes access permissions from everybody but the user, then proceeds to write some sensitive information (e.g. a private key) into it"? Sure, it might work ok in your scenario with a flash drive, but what if the directory is publicly readable?

Permissions aren't an application-level security mechanism. An application cannot do something like this without making many assumptions about control over the directory and the system configuration. It has to assume that other users don't have control over any of the path segments, for one thing. It lacks awareness of whether path-based MAC or something else is being used to provide the isolation instead of POSIX permission bits.