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 whole "rustc automatically determines the compatible version" idea is wishful thinking. There will be tons of subtle (and often unexpected) language/compiler/library changes that affect backwards compatibility across versions. This happens with every compiler/language/framework and while unfortunate, any expectations to the contrary are unrealistic.

Assuming that rustc can then automatically determine that any non-trivial library built and tested with rustc 1.5 will work just fine with rustc 1.3 because it only declares it's using features available from 1.3 onwards is again, wishful thinking. Such a library would have to be tested by the authors before one could confidently say it works with 1.3.

Any attempts at heuristically figuring out library & compiler/language compatibility will produce more hard than good. Someone will end up using a library that hasn't been tested with an older compiler version and if they're _extremely_ lucky, the library will fail in obvious ways. If they're unlucky, it will behave only slightly differently than the author of the library intended. 

A much better, simpler and more robust approach is to just enforce that a minimum language version is specified for a library. The KISS rule is a good idea here. Any attempts by a software system at "lets figure out what he user actually meant" almost always end in tears. Examples:

- The JavaScript equality table.
- "Error-correcting" parsers for HTML4.
- Perl.