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
>Could each module be linked into one module to be emitted? (is that too timing-intensive?)
I haven't tried this yet.  I don't think it would take much longer than we already spend linking the object files together.  The only problem is, all the LLVM modules are in separate contexts, so we would need to serialize each one and then deserialize into a shared context for linking.

>Otherwise, could we name the files bytecodeN.deflate and list how many bytecodes are in the metadata?
Yeah, this is my preferred solution (which I also haven't tried implementing yet).