Compile libc for each used feature set

[tlively]

This is particularly important for threads with the LLVM backend, since attempting to link against MVP libc will yield a helpful error message about atomics being disabled.

[dschuff]

Are we sure this is something we actually want to do, for all features?
For threads, the answer is probably yes, but as we add more features it seem like having every combination is infeasible, and may not even buy very much (will libc benefit very much from nontrapping float-to-int? from EH?)

At the bare minimum we'll need one for each ABI. That already includes threads, may include one for mutable global, and probably will eventually include one for multi-value. We want to minimize the number of ABIs (which in particular affects dynamic linking; all the more so if/when libc becomes dynamically linked) but it might be worthwhile to have extra static libcs if there's enough performance win. So it's maybe an open question as to what other combinations are useful. It might also be desirable to split some components out of a standard lib if we want extra duplicates of just a few functions (e.g. SIMD-based memcpy?)

[kripken]

I think this is basically done? We do build libc for multithreading, exceptions etc. as necessary.