compiletest: Run tests in their own thread to avoid blocking the scheduler

The calls to waitpid are interacting badly with the message passing that goes
on between schedulers and causing us to have very little parallelism in
the test suite. I don't fully understand the sequence of events that causes
the problem here but clearly blocking on waitpid is something that a
well-behaved task should not be doing.

Unfortunately this adds quite a bit of overhead to each test: one thread, two
tasks, three stacks, so there's a tradeoff. The time to execute run-pass on
my 4-core machine goes from ~750s to ~300s.
syntax: add a local_data_key macro that creates a key for access to the TLS.

This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that have to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
Add UUID support to libextra
- generate random UUIDs
- convert to and from strings and bytes
- parse common string formats
- implements Zero, Clone, FromStr, ToStr, Eq, TotalEq and Rand
- unit tests and documentation
- parsing error codes and strings
- incorporate feedback from PR review
auto merge of #8534 : huonw/rust/tls-key-macro, r=alexcrichton

This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that *have* to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
auto merge of #8531 : brson/rust/test-waitpid-workaround, r=graydon

...er

I believe the calls to waitpid are interacting badly with the message passing that goes
on between schedulers and causing us to have very little parallelism in
the test suite. I don't fully understand the sequence of events that causes
the problem here but clearly blocking on waitpid is something that a
well-behaved task should not be doing.

Unfortunately this adds quite a bit of overhead to each test: one thread, two
tasks, three stacks, so there's a tradeoff. The time to execute run-pass on
my 4-core machine goes from ~750s to ~300s.

This should have a pretty good impact on cycle times.

cc @toddaaro
auto merge of #8053 : gavinb/rust/uuid_std, r=alexcrichton

Addresses part of #7104

This module adds the ability to generate UUIDs (on all Rust-supported platforms).

I reviewed the existing UUID support in libraries for a range of languages; Go, D, C#, Java and Boost++. The features were all very similar, and this patch essentially covers the union.  The implmentation is quite straightforward, and uses the underlying rng support which is assumed to be sufficiently strong for this purpose.

This patch is not complete, however I have put this up for review to gather feedback before finalising. It has tests for most features and documentation for most functions.

Outstanding issues:

* Only generates V4 (Random) UUIDs. Do we want to support the SHA-1 hash based flavour as well?
* Is it worth having the field-based struct public as well as the byte array?
* Formatting the string with '-' between groups not done yet.
* Parsing full string not done as there appears to be no regexp support yet. I can write a simple manual parser for now?
* D has a generator as well. This would be easy to add. However, given the simple interface for creating a new one, and the presence of the macro, is this useful?
* Is it worth having a separate UUID trait and specific implementation? Or should it just have a struct+impl with the same name? Currently it feels weird to have the trait (which can't be named UUID so as to conflict) a separate thing.
* Should the macro be visible at the top level scope?

As this is a first attempt, some code may not be idiomatic. Please comment below...

Thanks for all feedback!
Fix warnings in tests
Fix warnings in librustc and libsyntax
Fix warnings it tests