(cleanup) Uncomment an assertion that now holds.
Lazily initialize 'leaf node' taskgroups for unlinked spawns, for an apparent 11% speedup.
Re-enable rusti tests
auto merge of #8317 : bblum/rust/fast-spawn-unlinked, r=brson

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();
    }
}
```
auto merge of #8321 : alexcrichton/rust/enable-rusti, r=cmr

Now that LLVM has been upgraded, I think that we can try again to re-enable the rusti tests.
iterator: simplify the `take` implementation
add Extendable to the prelude
iterator: rename `Counter::new` to `count`

to match the convention used by `range`, since `iterator::count` is
already namespaced enough and won't be ambiguous
remove the Times trait in favour of `range`

The `times` method is cute, but I don't think it's worth having just to
save a few characters now and then.

It's not possible to break from `times` and it results in the
restrictions coming from closures. Using `for _ in range(0, n)` from the
start is simpler, rather than switching to it after hitting either of
these issues.
remove `extra::iter`

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.
vec: avoid `ptrtoint`/`inttoptr` in the iterators

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.
add an intrinsic for inbounds GEP
vec: use `offset_inbounds` for iterators