Add a cfg_attr syntax extension

This extends cfg-gating to attributes.

```rust
 #[cfg_attr(<cfg pattern>, <attr>)]
```
will expand to
```rust
 #[<attr>]
```
if the `<cfg pattern>` matches the current cfg environment, and nothing
if it does not. The grammar for the cfg pattern has a simple
recursive structure:

 * `value` and `key = "value"` are cfg patterns,
 * `not(<cfg pattern>)` is a cfg pattern and matches if `<cfg pattern>`
    does not.
 * `all(<cfg pattern>, ...)` is a cfg pattern and matches if all of the
    `<cfg pattern>`s do.
 * `any(<cfg pattern>, ...)` is a cfg pattern and matches if any of the
    `<cfg pattern>`s do.

Examples:

```rust
 // only derive Show for assert_eq! in tests
 #[cfg_attr(test, deriving(Show))]
 struct Foo { ... }

 // only derive Show for assert_eq! in tests and debug builds
 #[cfg_attr(any(test, not(ndebug)), deriving(Show))]
 struct Foo { ... }

 // ignore a test in certain cases
 #[test]
 #[cfg_attr(all(not(target_os = "linux"), target_endian = "big"), ignore)]
 fn test_broken_thing() { ... }

 // Avoid duplication when fixing staging issues in rustc
 #[cfg_attr(not(stage0), lang="iter")]
 pub trait Iterator<T> { ... }
```
Deprecate `#[ignore(cfg(...))]`

Replace `#[ignore(cfg(a, b))]` with `#[cfg_attr(all(a, b), ignore)]`
Fix rebase fallout
Correct typo in the Iterator adapters section
guide-pointers.md: C sample code should match the Rust version.

Fix rust-lang/rust#17255
Fix typo in unsafe guide (s/xlibrary/library)
Fix free lifetime vars in HashMap's iterators
Correct tense
Add Option::{ok_or, ok_or_else}

These are the inverses of `Result::ok` and help to bridge `Option` and
`Result` based APIs.
librustc: Give trait methods accessible via fewer autoderefs priority
over inherent methods accessible via more autoderefs.

This simplifies the trait matching algorithm. It breaks code like:

    impl Foo {
        fn foo(self) {
            // before this change, this will be called
        }
    }

    impl<'a,'b,'c> Trait for &'a &'b &'c Foo {
        fn foo(self) {
            // after this change, this will be called
        }
    }

    fn main() {
        let x = &(&(&Foo));
        x.foo();
    }

To explicitly indicate that you wish to call the inherent method, perform
explicit dereferences. For example:

    fn main() {
        let x = &(&(&Foo));
        (***x).foo();
    }

Part of #17282.

[breaking-change]
auto merge of #17464 : pcwalton/rust/inherent-methods-on-equal-footing, r=nikomatsakis

over inherent methods accessible via more autoderefs.

This simplifies the trait matching algorithm. It breaks code like:

    impl Foo {
        fn foo(self) {
            // before this change, this will be called
        }
    }

    impl<'a,'b,'c> Trait for &'a &'b &'c Foo {
        fn foo(self) {
            // after this change, this will be called
        }
    }

    fn main() {
        let x = &(&(&Foo));
        x.foo();
    }

To explicitly indicate that you wish to call the inherent method, perform
explicit dereferences. For example:

    fn main() {
        let x = &(&(&Foo));
        (***x).foo();
    }

Part of #17282.

[breaking-change]

r? @nikomatsakis
auto merge of #17506 : sfackler/rust/cfg-attr, r=alexcrichton

cc #17490 

Reopening of #16230
auto merge of #17469 : sfackler/rust/into-result, r=aturon

This is the inverse of `Result::ok` and helps to bridge `Option` and
`Result` based APIs.
auto merge of #17512 : nodakai/rust/fix-ptr-guide, r=alexcrichton

Fix rust-lang/rust#17255

This is such a trivial change.  Devs: perhaps you might want to omit to run `make check` on Travis.
auto merge of #17515 : mbrubeck/rust/patch-1, r=alexcrichton

r? @steveklabnik
auto merge of #17511 : MatejLach/rust/iter_guide_typo, r=alexcrichton

The sentence "The new iterator `filter()` produces returns only the elements that that closure returned `true` for:"  can be structured as:

"The new iterator `filter()` produces only the elements that that closure returned `true` for:"

or as:

"The new iterator `filter()` returns only the elements that that closure returned `true` for:"

however, not both. 

I went with "produces", since it then talks about returning true and having "return" so close together doesn't sound nice. 
r @steveklabnik ?
complete btree rewrite

Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations.
BTreeMap's internal Node representation is particularly inefficient at the moment to
make this first implementation easy to reason about and fairly safe. Both collections
are also currently missing some of the tooling specific to sorted collections, which
is planned as future work pending reform of these APIs. General implementation issues
are discussed with TODOs internally

Perf results on x86_64 Linux:

test treemap::bench::find_rand_100                         ... bench:        76 ns/iter (+/- 4)
test treemap::bench::find_rand_10_000                      ... bench:       163 ns/iter (+/- 6)
test treemap::bench::find_seq_100                          ... bench:        77 ns/iter (+/- 3)
test treemap::bench::find_seq_10_000                       ... bench:       115 ns/iter (+/- 1)
test treemap::bench::insert_rand_100                       ... bench:       111 ns/iter (+/- 1)
test treemap::bench::insert_rand_10_000                    ... bench:       996 ns/iter (+/- 18)
test treemap::bench::insert_seq_100                        ... bench:       486 ns/iter (+/- 20)
test treemap::bench::insert_seq_10_000                     ... bench:       800 ns/iter (+/- 15)

test btree::map::bench::find_rand_100                      ... bench:        74 ns/iter (+/- 4)
test btree::map::bench::find_rand_10_000                   ... bench:       153 ns/iter (+/- 5)
test btree::map::bench::find_seq_100                       ... bench:        82 ns/iter (+/- 1)
test btree::map::bench::find_seq_10_000                    ... bench:       108 ns/iter (+/- 0)
test btree::map::bench::insert_rand_100                    ... bench:       220 ns/iter (+/- 1)
test btree::map::bench::insert_rand_10_000                 ... bench:       620 ns/iter (+/- 16)
test btree::map::bench::insert_seq_100                     ... bench:       411 ns/iter (+/- 12)
test btree::map::bench::insert_seq_10_000                  ... bench:       534 ns/iter (+/- 14)

BTreeMap still has a lot of room for optimization, but it's already beating out TreeMap on most access patterns.

[breaking-change]
auto merge of #17334 : Gankro/rust/btree-vec, r=huonw

Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations.
BTreeMap's internal Node representation is particularly inefficient at the moment to
make this first implementation easy to reason about and fairly safe. Both collections
are also currently missing some of the tooling specific to sorted collections, which
is planned as future work pending reform of these APIs. General implementation issues
are discussed with TODOs internally

[breaking-change]

Still waiting on compilation/test/bench stuff locally, but the edit-distance on any errors should be very small at this point. This is ready to be reviewed.
auto merge of #17517 : pczarn/rust/hashmap-lifetimes, r=alexcrichton

Fixes #17500