Reorganize llvm and clang libs and bindings

[brson]

Right now we have a native library, rustllvm, that contains LLVM + some extra Rust-specific glue-code, and we have hand-written LLVM bindings in rustc. Soon we will also need clang bindings.

As part of integrating bindgen and its clang bindings I would like to restructure our llvm libs.

The gist of it is that we have two rust crates, llvm and clang, which contain bindings and are statically linked to their native libraries. The primary benefit is that we will have no native libraries for rust-based llvm consumers to deal with. The secondary benefit is that it clearly exposes the rust APIs for llvm so other tools can use them.

[brson]

This arrangement probably won't work when it's time to make official Debian packages.

[Fiyorin]

when compiling the entire rust from a release tarball: why not depend on the host LLVM/Clang, if its installed?
"aptitude install llvm clang" and call it a day?
i'm getting build issues which are from fixed bugs in clang, which havent made it into rust yet, and the whole compile takes forever.
just an idea.

[brson]

We have a number of GC-related patches on our fork right now, but the goal is to work on stock LLVM eventually.

[brson]

With some effort we could probably get Rust to work with upstream LLVM, because the GC stuff is releatively self contained and only used in experimental builds.

[pnkfelix]

Not critical for 0.6; de-milestoning

[pnkfelix]

visiting for triage. I considered nominating this for a milestone, but honestly, I could imagine shipping 1.0 without teasing out our locally patched LLVM.

@brson When you said "This arrangement probably won't work when it's time to make official Debian packages.", which arrangement were you referring to? The current arrangement? Or the one you proposed? (my best guess is that you were referring to the current arrangement.)

[thestinger]

Debian and Fedora aren't going to care for us not using the upstream LLVM, and we're going to need to be able to use the system libuv/gyp.

[alexcrichton]

We have no clang bindings, and otherwise all the points of the issue have been worked out. The llvm and rustllvm libraries are both statically linked into rustc, so we don't have to worry about their distribution at all any more.

Closing in favor of #8275 (which is what's left to do on this issue).