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)
After thinking about this some more, if the error type is going to become an associated type, there's an open question about how we handle expressing `EndOfFile`. As specified in this RFC, there's no way for a generic consumer to know if a `read` or `write` has hit the end of the file. I think we have two options to address this. First, we define a return of `Ok(0)` as representing the end of file. Second, we constrain the error type to another trait, as in:

```rust
trait Reader {
    type Err: Error,
    ...
}

trait Error {
    fn is_eof(&self) -> bool;
}
```

I'm personally leaning right now for the first option for a couple reasons:

* I find it a little weird having some ambiguity on what a zero length return means.
* C libraries return 0 if `read` has hit the end of the stream.
* The end of a stream isn't necessarily an error.
* There is a chance the cpu/llvm may be able to better optimize reads to the first slot of Result<uint, E>, and put error handling on a cold path.