Reserve `do` as a keyword

Resolves issue #12157. `do` is hereby reinstated as a keyword; no syntax is
associated with it though. Along the way, a unit test had to be adapted, since
it was using `do` as a method identifier.

Breaking changes:

- Any code using `do` as an identifier will no longer work.
Ignore #[phase] on use view items

Closes #11806
Output the correct library filename with --dep-info

Fixes #12174.
auto merge of #12159 : alexcrichton/rust/move-fourcc, r=kballard

It depends on libsyntax, which is a host crate, so it can't be in the target
crates section.
auto merge of #12170 : aepsil0n/rust/feature/reserve_do_keyword, r=brson

This resolves issue #12157. Does that do it already or is there something else that needs taking care of?  

As a side note, there seems to be some documentation, in which the old existence of the do keyword is explained. The list of keywords is not up-to-date either. But these are certainly separate issues.
Factoring bigint, rational, and complex out of libextra into libnum.

Removed use of globs present in earlier versions of modules.

Fix tutorial.md to reflect `extra::rational` ==> `num::rational`.
auto merge of #12175 : sfackler/rust/phase-use-ignored, r=alexcrichton

It could throw an error but I think it's best to not since `#[phase(..)]` syntax in other places would be silently ignored.

Closes #11806
auto merge of #12154 : pnkfelix/rust/fsk-factor-bigint-and-rat-out-of-libextra, r=alexcrichton

Removed use of globs present in earlier versions of modules.

Fix tutorial.md to reflect `extra::rational` ==> `num::rational`.
auto merge of #12176 : kballard/rust/dep-info-lib-filename, r=alexcrichton

Fixes #12174.
Correct span for self and ExprStruct
auto merge of #12177 : alexcrichton/rust/fix-snapshot, r=kballard

This is blocking a snapshot because the stage0 target compiler comes from a
stage1 host compiler. This means that the stage0 compiler doesn't actually
understand the -Z prefer-dynamic flag and is dying as a result.

This will get added back to stage0 after a snapshot.
auto merge of #12181 : sanxiyn/rust/accurate-span-4, r=alexcrichton
Change `xfail` directives in compiletests to `ignore`, closes #11363
auto merge of #12110 : fhahn/rust/issue-11363-change-xfail, r=alexcrichton

Patch for #11363
Expose whether event loops have active I/O

The green scheduler can optimize its runtime based on this by deciding to not go
to sleep in epoll() if there is no active I/O and there is a task to be stolen.

This is implemented for librustuv by keeping a count of the number of tasks
which are currently homed. If a task is homed, and then performs a blocking I/O
operation, the count will be nonzero while the task is blocked. The homing count
is intentionally 0 when there are I/O handles, but no handles currently blocked.
The reason for this is that epoll() would only be used to wake up the scheduler
anyway.

The crux of this change was to have a `HomingMissile` contain a mutable borrowed
reference back to the `HomeHandle`. The rest of the change was just dealing with
this fallout. This reference is used to decrement the homed handle count in a
HomingMissile's destructor.

Also note that the count maintained is not atomic because all of its
increments/decrements/reads are all on the same I/O thread.
Percolate the (Scheduler, GreenTask) pair upwards

This is in preparation for running do_work in a loop while there are no active
I/O handles. This changes the do_work and interpret_message_queue methods to
return a triple where the last element is a boolean flag as to whether work was
done or not.

This commit preserves the same behavior as before, it simply re-structures the
code in preparation for future work.
Don't hit epoll unless a scheduler absolutely must

Currently, a scheduler will hit epoll() or kqueue() at the end of *every task*.
The reason is that the scheduler will context switch back to the scheduler task,
terminate the previous task, and then return from run_sched_once. In doing so,
the scheduler will poll for any active I/O.

This shows up painfully in benchmarks that have no I/O at all. For example, this
benchmark:

    for _ in range(0, 1000000) {
        spawn(proc() {});
    }

In this benchmark, the scheduler is currently wasting a good chunk of its time
hitting epoll() when there's always active work to be done (run with
RUST_THREADS=1).

This patch uses the previous two commits to alter the scheduler's behavior to
only return from run_sched_once if no work could be found when trying really
really hard. If there is active I/O, this commit will perform the same as
before, falling back to epoll() to check for I/O completion (to not starve I/O
tasks).

In the benchmark above, I got the following numbers:

    12.554s on today's master
    3.861s  with #12172 applied
    2.261s  with both this and #12172 applied

cc #8341