The `extra::iter` module wasn't actually included in `extra.rs` when it was moved from `std`... I assume no one is going to miss it.

These are causing problems on the linux bots, I'll investigate soon.

This reverts commit d5de801c.

The two deletions are because the test cases are very old (still using `class` and modes!), and, as far as I can tell (since they are so old), the areas they test are well tested by other rpass tests.

Fixes #7302.

Fixes #7304.

Fixes #7305, #7307.

Closes #3682.

Implement saturating math in `std::num::Saturating` and use it for `Iterator` impls

Some general clean-up relating to deriving:
- `TotalOrd` was too eager, and evaluated the `.cmp` call for every field, even if it could short-circuit earlier.
- the pointer types didn't have impls for `TotalOrd` or `TotalEq`.
- the Makefiles didn't reach deep enough into libsyntax for dependencies.

(Split out from https://github.com/mozilla/rust/pull/8258.)

FromHex ignores whitespace and parses either upper or lower case hex
digits. ToHex outputs lower case hex digits with no whitespace. Unlike
ToBase64, ToHex doesn't allow you to configure the output format. I
don't feel that it's super useful in this case.

This allows LLVM to optimize vector iterators to an `getelementptr` and
`icmp` pair, instead of `getelementptr` and *two* comparisons.

Code snippet:

~~~
fn foo(xs: &mut [f64]) {
    for x in xs.mut_iter() {
        *x += 10.0;
    }
}
~~~

LLVM IR at stage0:

~~~
; Function Attrs: noinline uwtable
define void @"_ZN3foo17_68e1b25bca131dba7_0$x2e0E"({ i64, %tydesc*, i8*, i8*, i8 }* nocapture, { double*, i64 }* nocapture) #1 {
"function top level":
  %2 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 0
  %3 = load double** %2, align 8
  %4 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 1
  %5 = load i64* %4, align 8
  %6 = ptrtoint double* %3 to i64
  %7 = and i64 %5, -8
  %8 = add i64 %7, %6
  %9 = inttoptr i64 %8 to double*
  %10 = icmp eq double* %3, %9
  %11 = icmp eq double* %3, null
  %or.cond6 = or i1 %10, %11
  br i1 %or.cond6, label %match_case, label %match_else

match_else:                                       ; preds = %"function top level", %match_else
  %12 = phi double* [ %13, %match_else ], [ %3, %"function top level" ]
  %13 = getelementptr double* %12, i64 1
  %14 = load double* %12, align 8
  %15 = fadd double %14, 1.000000e+01
  store double %15, double* %12, align 8
  %16 = icmp eq double* %13, %9
  %17 = icmp eq double* %13, null
  %or.cond = or i1 %16, %17
  br i1 %or.cond, label %match_case, label %match_else

match_case:                                       ; preds = %match_else, %"function top level"
  ret void
}
~~~

Optimized LLVM IR at stage1/stage2:

~~~
; Function Attrs: noinline uwtable
define void @"_ZN3foo17_68e1b25bca131dba7_0$x2e0E"({ i64, %tydesc*, i8*, i8*, i8 }* nocapture, { double*, i64 }* nocapture) #1 {
"function top level":
  %2 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 0
  %3 = load double** %2, align 8
  %4 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 1
  %5 = load i64* %4, align 8
  %6 = lshr i64 %5, 3
  %7 = getelementptr inbounds double* %3, i64 %6
  %8 = icmp eq i64 %6, 0
  %9 = icmp eq double* %3, null
  %or.cond6 = or i1 %8, %9
  br i1 %or.cond6, label %match_case, label %match_else

match_else:                                       ; preds = %"function top level", %match_else
  %.sroa.0.0.in7 = phi double* [ %10, %match_else ], [ %3, %"function top level" ]
  %10 = getelementptr inbounds double* %.sroa.0.0.in7, i64 1
  %11 = load double* %.sroa.0.0.in7, align 8
  %12 = fadd double %11, 1.000000e+01
  store double %12, double* %.sroa.0.0.in7, align 8
  %13 = icmp eq double* %10, %7
  br i1 %13, label %match_case, label %match_else

match_case:                                       ; preds = %match_else, %"function top level"
  ret void
}
~~~

This results in throwing away alias analysis information, because LLVM
does *not* implement reasoning about these conversions yet.

We specialize zero-size types since a `getelementptr` offset will
return us the same pointer, making it broken as a simple counter.

This module provided adaptors for the old internal iterator protocol,
but they proved to be quite unreadable and are not generic enough to
handle borrowed pointers well.

Since Rust no longer defines an internal iteration protocol, I don't
think there's going to be any reuse via these adaptors.

Original pull request: Add str.to_ascii_lower() and str.to_ascii_upper() methods in std::str.

to match the convention used by `range`, since `iterator::count` is
already namespaced enough and won't be ambiguous

Now that LLVM has been upgraded, I think that we can try again to re-enable the rusti tests.

This lazily initializes the taskgroup structs for ```spawn_unlinked``` tasks. If such a task never spawns another task linked to it (or a descendant of it), its taskgroup is simply never initialized at all. Also if an unlinked task spawns another unlinked task, neither of them will need to initialize their taskgroups. This works for the main task too.

I benchmarked this with the following test case and observed a ~~21% speedup (average over 4 runs: 7.85 sec -> 6.20 sec, 2.5 GHz)~~ 11% speedup, see comment below.
```
use std::task;
use std::cell::Cell;
use std::rt::comm;

static NUM: uint = 1024*256;

fn run(f: ~fn()) {
    let mut t = task::task();
    t.unlinked();
    t.spawn(f);
}

fn main() {
    do NUM.times {
        let (p,c) = comm::oneshot();
        let c = Cell::new(c);
        do run { c.take().send(()); }
        p.recv();
    }
}
```

Encoding should really only be done from [u8]<->str. The extra
convenience implementations don't really have a place, especially since
they're so trivial.

Also improved error messages in FromBase64.

String NULL terminators are going away soon, so we may as well get rid
of this now so it doesn't rot.

The overhead of str::push_char is high enough to cripple the performance
of these two functions. I've switched them to build the output in a
~[u8] and then convert to a string later. Since we know exactly the
bytes going into the vector, we can use the unsafe version to avoid the
is_utf8 check.

I could have riced it further with vec::raw::get, but it only added
~10MB/s so I didn't think it was worth it. ToHex is still ~30% slower
than FromHex, which is puzzling.

Before:

```
test base64::test::from_base64 ... bench: 1000 ns/iter (+/- 349) = 204 MB/s
test base64::test::to_base64 ... bench: 2390 ns/iter (+/- 1130) = 63 MB/s
...
test hex::tests::bench_from_hex ... bench: 884 ns/iter (+/- 220) = 341 MB/s
test hex::tests::bench_to_hex ... bench: 2453 ns/iter (+/- 919) = 61 MB/s
```

After:

```
test base64::test::from_base64 ... bench: 1271 ns/iter (+/- 600) = 160 MB/s
test base64::test::to_base64 ... bench: 759 ns/iter (+/- 286) = 198 MB/s
...
test hex::tests::bench_from_hex ... bench: 875 ns/iter (+/- 377) = 345 MB/s
test hex::tests::bench_to_hex ... bench: 593 ns/iter (+/- 240) = 254 MB/s
```

FromHex ignores whitespace and parses either upper or lower case hex
digits. ToHex outputs lower case hex digits with no whitespace. Unlike
ToBase64, ToHex doesn't allow you to configure the output format. I
don't feel that it's super useful in this case.