std: Replace `for` with `do { .. }` expr in std::gc

Change all users of old-style for with internal iterators to using
`do`-loops.

The code in stackwalk.rs does not actually implement the
looping protocol (no break on return false).

The code in gc.rs does not use loop breaks, nor does any code using it.

We remove the capacity to break from the loops in std::gc and implement
the walks using `do { .. }` expressions.

No behavior change.
std: Change `Times` trait to use `do` instead of `for`

Change the former repetition::

    for 5.times { }

to::

    do 5.times { }

.times() cannot be broken with `break` or `return` anymore; for those
cases, use a numerical range loop instead.
auto merge of #8165 : graydon/rust/2013-07-31-new-codegen-tests, r=brson

r? @pcwalton or someone
auto merge of #8166 : emillon/rust/clean-tests-mk, r=brson

Hello,

While looking at `tests.mk` I noticed two errors:

  - there's a `srcrustllvm` instead of `src/rustllvm`
  - some filtered out files don't exist anymore

These two commits fix these issues. Thanks!
rustc: add a lint for `for`, suggesting `foreach` or `do`.

This is just to aid the transistion to the new `for` loop, by
pointing at each location where the old one occurs.
Remove the pipes compiler

The pipes compiler produced data types that encoded efficient and safe
bounded message passing protocols between two endpoints. It was also
capable of producing unbounded protocols.

It was useful research but was arguably done before its proper time.

I am removing it for the following reasons:

* In practice we used it only for producing the `oneshot` and `stream`
  unbounded protocols and all communication in Rust use those.
* The interface between the proto! macro and the standard library
  has a large surface area and was difficult to maintain through
  language and library changes.
* It is now written in an old dialect of Rust and generates code
  which would likely be considered non-idiomatic.
* Both the compiler and the runtime are difficult to understand,
  and likewise the relationship between the generated code and
  the library is hard to understand. Debugging is difficult.
* The new scheduler implements `stream` and `oneshot` by hand
  in a way that will be significantly easier to maintain.

This shouldn't be taken as an indication that 'channel protocols'
for Rust are not worth pursuing again in the future.
migrate to foreach
Add a boatload of Linux x86/x86-64/arm errnos
auto merge of #8190 : thestinger/rust/for, r=thestinger
Relax some atomic barriers. Loosen up all that tension. There, doesn't that feel good?
Document task killing design and relaxed barrier rationale.
Make a forgotten assert in comm be cfg(test)-dependent
Temporary workaround to prevent taskgroup cleanup code from failing without an exception handler.
auto merge of #8170 : brson/rust/nopipes, r=pcwalton

The pipes compiler produced data types that encoded efficient and safe
bounded message passing protocols between two endpoints. It was also
capable of producing unbounded protocols.

It was useful research but was arguably done before its proper time.

I am removing it for the following reasons:

* In practice we used it only for producing the `oneshot` protcol  and
  the unbounded `stream` protocol and all communication in Rust use those.
* The interface between the proto! macro and the standard library
  has a large surface area and was difficult to maintain through
  language and library changes.
* It is now written in an old dialect of Rust and generates code
  which would likely be considered non-idiomatic.
* Both the compiler and the runtime are difficult to understand,
  and likewise the relationship between the generated code and
  the library is hard to understand. Debugging is difficult.
* The new scheduler implements `stream` and `oneshot` by hand
  in a way that will be significantly easier to maintain.

This shouldn't be taken as an indication that 'channel protocols'
for Rust are not worth pursuing again in the future.

Concerned parties may include: @graydon, @pcwalton, @eholk, @bblum

The most likely candidates for closing are #7666, #3018, #3020, #7021, #7667, #7303, #3658, #3295.
A major refactoring that changes the way the runtime uses TLS. In the
old design the TLS held the scheduler struct, and the scheduler struct
held the active task. This posed all sorts of weird problems due to
how we wanted to use the contents of TLS. The cleaner approach is to
leave the active task in TLS and have the task hold the scheduler. To
make this work out the scheduler has to run inside a regular task, and
then once that is the case the context switching code is massively
simplified, as instead of three possible paths there is only one. The
logical flow is also easier to follow, as the scheduler struct acts
somewhat like a "token" indicating what is active.

These changes also necessitated changing a large number of runtime
tests, and rewriting most of the runtime testing helpers.

Polish level is "low", as I will very soon start on more scheduler
changes that will require wiping the polish off. That being said there
should be sufficient comments around anything complex to make this
entirely respectable as a standalone commit.
Have linked failure tests run on the new scheduler instead of requiring RUST_NEWRT to test.
Fixed a race where a scheduler configured to only run tasks pinned to it would "bounch" a regular task in and out of the work queue without allowing a different scheduler to run it.
minor tweaks - unboxed the coroutine so that it is no longer a ~ pointer inside the task struct, and also added an assert to verify that send is never called inside scheduler context as it is undefined (BROKEN) if that happens
fixed incorrect handling of returned scheduler option and restructed scheduler functions slightly
modified local to include an implementation for try_unsafe_borrow::<Task> so that the log methods will work