Add std::iterator::order with lexical ordering functions for sequences

Use Eq + Ord for lexicographical ordering of sequences.

For each of <, <=, >= or > as R, use::

    [x, ..xs] R [y, ..ys]  =  if x != y { x R y } else { xs R ys }

Previous code using `a < b` and then `!(b < a)` for short-circuiting
fails on cases such as  [1.0, 2.0] < [0.0/0.0, 3.0], where the first
element was effectively considered equal.
extra::dlist: Use iterator::order for sequence ordering
std: Implement traits for the one-tuple

(A,) did not have the trait implementations of 2- to 12- tuples.
std::vec: Use iterator::order functions for Eq, Ord, TotalOrd, TotalEq
std: Fix Ord for Option, using iterator::order
std: Fix tuple lexicographical order

Use the definition, where R is <, <=, >=, or >

    [x, ..xs] R [y, ..ys]  =  if x != y { x R y } else { xs R ys }

Previously, tuples would only implement < and derive the other
comparisons from it; this is incorrect. Included are several testcases
involving NaN comparisons that are now correct.

Previously, tuples would consider an element equal if both a < b and
b < a were false, this was also incorrect.
std::iterator::order test cases
std::vec: Fix typo in fn ne
std::tuple: Use != properly in Eq::ne for tuples

Just like the Ord methods, Eq::ne needs to be implemented in terms of
the same operation on the elements.
Add parse-error recovery for erroneous `struct_id { }` form.

There are 4 different new tests, to check some different scenarios for
what the parse context is at the time of recovery, becasue our
compile-fail infrastructure does not appear to handle verifying
error-recovery situations.

Differentiate between unit-like struct definition item and unit-like
struct construction in the error message.

----

More generally, outlines a more generic strategy for parse error
recovery: By committing to an expression/statement at set points in
the parser, we can then do some look-ahead to catch common mistakes
and skip over them.

One detail about this strategy is that you want to avoid emitting the
"helpful" message unless the input is reasonably close to the case of
interest.  (E.g. do not warn about a potential unit struct for an
input of the form `let hmm = do foo { } { };`)

To accomplish this, I added (partial) last_token tracking; used for
`commit_stmt` support.

The check_for_erroneous_unit_struct_expecting fn returns bool to
signal whether it "made progress"; currently unused; this is meant for
use to compose several such recovery checks together in a loop.
Implement an `address_insignificant` attribute

This can be applied to statics and it will indicate that LLVM will attempt to
merge the constant in .data with other statics.

I have preliminarily applied this to all of the statics generated by the new
`ifmt!` syntax extension. I compiled a file with 1000 calls to `ifmt!` and a
separate file with 1000 calls to `fmt!` to compare the sizes, and the results
were:

fmt           310k
ifmt (before) 529k
ifmt (after)  202k

This now means that ifmt! is both faster and smaller than fmt!, yay!
rustc: Obey RUST_MIN_STACK env var

A lot of people are hitting stack overflows in rustc. This will make it
easier to experiment with stack size.
docs: In rustpkg manual, note future plans about versions
rustc: Add --target-cpu flag to select a more specific processor instead of the default, 'generic'.
std::iterator: Rename .peek() to .inspect()
Add a "peekable" iterator adaptor, with a peek() method that returns the next element.
extra::treemap: Use IteratorUtil::peekable

Replace the previous equivalent iterator adaptor with .peekable().
Refactor the set operation iterators so that they are easier to read.
syntax: Shrink enum Token and enum nonterminal

`enum Token` was 192 bytes (64-bit), as pointed out by pnkfelix; the only
bloating variant being `INTERPOLATED(nonterminal)`.

Updating `enum nonterminal` to use ~ where variants included big types,
shrunk size_of(Token) to 32 bytes (64-bit).

I am unsure if the `nt_ident` variant should have an indirection, with
ast::ident being only 16 bytes (64-bit), but without this, enum Token
would be 40 bytes.

A dumb benchmark says that compilation time is unchanged, while peak
memory usage for compiling std.rs is down 3%

Before::

    $ time ./x86_64-unknown-linux-gnu/stage1/bin/rustc --cfg stage1 src/libstd/std.rs
    19.00user 0.39system 0:19.41elapsed 99%CPU (0avgtext+0avgdata 627820maxresident)k
    0inputs+28896outputs (0major+228665minor)pagefaults 0swaps
    $ time ./x86_64-unknown-linux-gnu/stage1/bin/rustc -O --cfg stage1 src/libstd/std.rs
    31.64user 0.34system 0:32.02elapsed 99%CPU (0avgtext+0avgdata 629876maxresident)k
    0inputs+22432outputs (0major+229411minor)pagefaults 0swaps

After::

    $ time ./x86_64-unknown-linux-gnu/stage1/bin/rustc --cfg stage1 src/libstd/std.rs
    19.07user 0.45system 0:19.55elapsed 99%CPU (0avgtext+0avgdata 609384maxresident)k
    0inputs+28896outputs (0major+221997minor)pagefaults 0swaps

    $ time ./x86_64-unknown-linux-gnu/stage1/bin/rustc -O --cfg stage1 src/libstd/std.rs
    31.90user 0.34system 0:32.28elapsed 99%CPU (0avgtext+0avgdata 612080maxresident)k
    0inputs+22432outputs (0major+223726minor)pagefaults 0swaps
vec: optimize the Add implementation

before:

test add ... bench: 164 ns/iter (+/- 1)

after:

test add ... bench: 113 ns/iter (+/- 2)
str: optimize `with_capacity`

before:

test bench_with_capacity ... bench: 104 ns/iter (+/- 4)

after:

test bench_with_capacity ... bench: 56 ns/iter (+/- 1)