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).
We do understand that this is not a rock-solid guarantee (what the minimum version of a crate is), but we also see the benefits of this detection to far outweigh the alternatives. One alternative (which it sounds like @Valloric is arguing for) is to simply do nothing, but this is strictly less useful than the system proposed here. If the compiler detects that 1.3 is required, then it must have *at least* 1.3, the failure mode is if a newer compiler is actually required. This is why a manual specification via `Cargo.toml` is allowed if necessary. We do not expect the majority of code to require a custom annotation in their `Cargo.toml` to request a particular nightly version.

Put another way, I personally doubt that adding this infrastructure will do more harm than good, and I also personally expect it to be quite a useful tool in upgrading rustc over time.