WIP: groundwork for allowing `cargo install`

[oli-obk]

This requires clippy to be statically linkable (simply removing all plugin-related configurations does this). To do this properly, clippy would need to be split into a staticlib crate and a plugin crate that uses the staticlib crate. Then cargo-clippy can use the staticlib crate

cc @Manishearth

There's lots of hacky code in here to detect lib.rs and main.rs and it the code assumes that cargo build already ran (without --release). This will obviously be done right in case this is the way that we should go forward.

fixes #11

[Manishearth]

I'd prefer cargo install clippy to work, really; with tweaks to cargo install so that it can cache dependencies somewhere.

But this is a good step forward. My main gripe is that by replicating rustc_driver we're introducing a lot more instability.

[Manishearth]

Oh, we're using CompilerCalls; I forgot that existed. Previous gripe rescinded.

(I'm open to merging this into clippy itself as a binary, if it would work that way. cargo install clippy would be nice to have)

[oli-obk]

But this is a good step forward. My main gripe is that by replicating rustc_driver we're introducing a lot more instability.

Oh, we're using CompilerCalls; I forgot that existed. Previous gripe rescinded.

one thing is that I just copied out the code (from rustc_driver) that moves lints and stuff from Registry to Session. But since we know the kind of things clippy does, we can limit it to just early and late lint passes, thus reducing breakage-surface.

[oli-obk]

(I'm open to merging this into clippy itself as a binary, if it would work that way. cargo install clippy would be nice to have)

Shouldn't be a problem. I'll open a PR for splitting clippy into plugin and staticlib as a first step.

[oli-obk]

this has been implemented on clippy directly