mk: Fix non-android cross builds.
auto merge of #12172 : alexcrichton/rust/green-improvements, r=brson

These commits pick off some low-hanging fruit which were slowing down spawning green threads. The major speedup comes from fixing a bug in stack caching where we never used any cached stacks!

The program I used to benchmark is at the end. It was compiled with `rustc --opt-level=3 bench.rs --test` and run as `RUST_THREADS=1 ./bench --bench`. I chose to use `RUST_THREADS=1` due to #11730 as the profiles I was getting interfered too much when all the schedulers were in play (and shouldn't be after #11730 is fixed). All of the units below are in ns/iter as reported by `--bench` (lower is better).

|               | green | native | raw    |
| ------------- | ----- | ------ | ------ |
| osx before    | 12699 | 24030  | 19734  |
| linux before  | 10223 | 125983 | 122647 |
| osx after     |  3847 | 25771  | 20835  |
| linux after   |  2631 | 135398 | 122765 |

Note that this is *not* a benchmark of spawning green tasks vs native tasks. I put in the native numbers just to get a ballpark of where green tasks are. This is benchmark is *clearly* benefiting from stack caching. Also, OSX is clearly not 5x faster than linux, I think my VM is just much slower.

All in all, this ended up being a nice 4x speedup for spawning a green task when you're using a cached stack.

```rust
extern mod extra;
extern mod native;
use std::rt::thread::Thread;

#[bench]
fn green(bh: &mut extra::test::BenchHarness) {
    let (p, c) = SharedChan::new();
    bh.iter(|| {
        let c = c.clone();
        spawn(proc() {
            c.send(());
        });
        p.recv();
    });
}

#[bench]
fn native(bh: &mut extra::test::BenchHarness) {
    let (p, c) = SharedChan::new();
    bh.iter(|| {
        let c = c.clone();
        native::task::spawn(proc() {
            c.send(());
        });
        p.recv();
    });
}

#[bench]
fn raw(bh: &mut extra::test::BenchHarness) {
    bh.iter(|| {
        Thread::start(proc() {}).join()
    });
}
```
compiletest: Run all android tests serially

This is an attempt to isolate test failures on the bots. It may also
eliminate problems with the emulators breaking by reducing the chance
of OOM.
Stop looping on error waiting for android test results

These seem to be causing iloops on the bots. Let's rather see the errors.
auto merge of #12256 : brson/rust/android, r=alexcrichton

Android bot has been having some problems. A few details in the commits.
Tweak ItemDecorator API

The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
Refactored ast_map and friends, mainly to have Paths without storing them.
auto merge of #12162 : eddyb/rust/ast-map-cheap-path, r=nikomatsakis
auto merge of #12186 : alexcrichton/rust/no-sleep-2, r=brson

Any single-threaded task benchmark will spend a good chunk of time in `kqueue()` on osx and `epoll()` on linux, and the reason for this is that each time a task is terminated it will hit the syscall. When a task terminates, it context switches back to the scheduler thread, and the scheduler thread falls out of `run_sched_once` whenever it figures out that it did some work.

If we know that `epoll()` will return nothing, then we can continue to do work locally (only while there's work to be done). We must fall back to `epoll()` whenever there's active I/O in order to check whether it's ready or not, but without that (which is largely the case in benchmarks), we can prevent the costly syscall and can get a nice speedup.

I've separated the commits into preparation for this change and then the change itself, the last commit message has more details.
auto merge of #12192 : luqmana/rust/fix-cross, r=alexcrichton

Fix some fall out from the big command line option changes.
auto merge of #12234 : sfackler/rust/restructure-item-decorator, r=huonw

The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.

@huonw
Tweak how preference factors into linkage

The new methodology can be found in the re-worded comment, but the gist of it is
that -C prefer-dynamic doesn't turn off static linkage. The error messages
should also be a little more sane now.

Closes #12133
Re-work loading crates with nicer errors

This commit rewrites crate loading internally in attempt to look at less
metadata and provide nicer errors. The loading is now split up into a few
stages:

1. Collect a mapping of (hash => ~[Path]) for a set of candidate libraries for a
   given search. The hash is the hash in the filename and the Path is the
   location of the library in question. All candidates are filtered based on
   their prefix/suffix (dylib/rlib appropriate) and then the hash/version are
   split up and are compared (if necessary).

   This means that if you're looking for an exact hash of library you don't have
   to open up the metadata of all libraries named the same, but also in your
   path.

2. Once this mapping is constructed, each (hash, ~[Path]) pair is filtered down
   to just a Path. This is necessary because the same rlib could show up twice
   in the path in multiple locations. Right now the filenames are based on just
   the crate id, so this could be indicative of multiple version of a crate
   during one crate_id lifetime in the path. If multiple duplicate crates are
   found, an error is generated.

3. Now that we have a mapping of (hash => Path), we error on multiple versions
   saying that multiple versions were found. Only if there's one (hash => Path)
   pair do we actually return that Path and its metadata.

With this restructuring, it restructures code so errors which were assertions
previously are now first-class errors. Additionally, this should read much less
metadata with lots of crates of the same name or same version in a path.

Closes #11908