Release channels take 2

This RFC describes changes to the Rust release process, primarily the division of Rust's time-based releases into 'release channels', following the 'release train' model used by e.g. Firefox and Chrome; as well as 'feature staging', which enables the continued development of experimental language features and libraries APIs while providing strong stability guarantees in stable releases.

This revision includes a significant simplification by merging stability attributes with feature gates, which further enables some additional useful features within Cargo related to version detection. One big implication of this change is that stability attributes are no longer suitable for use outside of std (if such a feature is desirable it is intended to be solved by Cargo).
@quantheory it's not clear how the stability attributes can possibly interact with other libraries to us. The major purpose of this is to *prevent access entirely* to `#[unstable]` APIs, not to just warn-on-use. With this form of model, how would the compiler allow or disallow access to unstable APIs in arbitrary libraries? The compiler itself has very little knowledge of versioning, especially of libraries themselves, and almost all of the benefits of the stability attributes here are gained through libraries declaring semver-requirement dependencies on one another themselves.

To expand on the design for Cargo, I envision the ability to have unstable features in Cargo manifest (note I mean [Cargo features](http://doc.crates.io/manifest.html#the-%5Bfeatures%5D-section), not stability-attribute features). Packages are then required to opt-in to these features, and packages published to crates.io will not have any experimental features. This is largely what I think external libraries would desired with respect to stability attributes because:

1. Experimental features can be developed in the upstream source repository. Users of stable versions of a library do not have access to them.
2. Applications can *opt-in* to using experimental features by depending on the repository.
3. All features are tracked by name and there's a clear path to accepting features for libraries themselves (and a clear place to put the list of features).

---

@emk I'm curious on your thoughts of what I've said above. The stability attributes were never really tasked with being a general purpose mechanism for all libraries and would require significant redesign to work as-is. All of this infrastructure is very specific to the *language version* which does not apply to external libraries.

Also note that all libraries other than the standard library have a *huge* advantage which is that they are published through crates.io. Management of multiple versions of a library is super easy, as well as declaring dependencies.

All in all, we have personally been able to come up with a concrete use case where stability attributes provide guarantees for external libraries that Cargo does not already do so. With this in mind, we've architected the current iteration towards more favoring the compiler and language and planning for similar functionality through Cargo externally if necessary