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).
This is rather cold comfort. The stability attributes:

- Are fairly simple/generic source code annotations.
- Have benefits that are widely applicable and hard to get by any other method (affecting rustdoc output in a pretty way, rustc warnings).
- Don't assume anything that a project's stabilization policies or processes remotely resemble those of the standard library.
- Don't assume that Cargo is being used for the build system/package manager in the first place.

So this is a useful thing that will be dropped, with a vague hope that something similar (but possibly less generic and more presumptuous) will be designed for Cargo in the hazy future. I'm wondering if it's really necessary to confine the stability attributes to the compiler and standard library (as opposed to adding this system in a way that doesn't affect the existing stability attributes, or at least unstable/stable/deprecated).