parallelize LLVM optimization and codegen passes

This branch adds support for running LLVM optimization and codegen on different parts of a crate in parallel.  Instead of translating the crate into a single LLVM compilation unit, `rustc` now distributes items in the crate among several compilation units, and spawns worker threads to optimize and codegen each compilation unit independently.  This improves compile times on multicore machines, at the cost of worse performance in the compiled code.  The intent is to speed up build times during development without sacrificing too much optimization.

On the machine I tested this on, `librustc` build time with `-O` went from 265 seconds (master branch, single-threaded) to 115s (this branch, with 4 threads), a speedup of 2.3x.  For comparison, the build time without `-O` was 90s (single-threaded).  Bootstrapping `rustc` using 4 threads gets a 1.6x speedup over the default settings (870s vs. 1380s), and building `librustc` with the resulting stage2 compiler takes 1.3x as long as the master branch (44s vs.  55s, single threaded, ignoring time spent in LLVM codegen).

The user-visible changes from this branch are two new codegen flags:

 * `-C codegen-units=N`: Distribute items across `N` compilation units.
 * `-C codegen-threads=N`: Spawn `N` worker threads for running optimization and codegen.  (It is possible to set `codegen-threads` larger than `codegen-units`, but this is not very useful.)

Internal changes to the compiler are described in detail on the individual commit messages.

Note: The first commit on this branch is copied from #16359, which this branch depends on.

r? @nick29581
In the past I have seen `ld -r` produce some very odd object files that turn out to not work at all. I initially intended for `ld -r` to be used to link together the rust object with all native static libraries to produce *one* object to put inside of an rlib (I even went as far as to hope that the object could be the rlib itself). I ended up abandoning that strategy once I saw that `ld -r` was flaky across platforms.

Sadly I don't quite remember what errors I was seeing, nor why I abandoned the strategy (specific errors encountered). We may want to not perform `ld -r` in the meantime. On the other hand, have you confirmed this object to be usable? It may be difficult to verify that as you'd probably still need to link to upstream libraries and such, but it may be a good smoke test!