Shade the compiler jar

[JakeWharton]

The compiler should be self-contained so as to not cause dependency resolution problems with our upstream library usage choices.

Cross filed for v1 at square#451.

[gk5885]

I'm always ambivalent about shading. It's really practical, but builds with multiple versions a single library always seem to be confusing and fragile. Regardless, it's a reasonable thing to want to do, so I'm +1 for any such contribution.

[JakeWharton]

The issue here is really JavaWriter and not so much Guava (although over a long-enough timeline Guava does present this problem). Processors relying on v2 will have their dependency replaced by v3 due to normal version resolving semantics and ultimately fail.

We've already had problems with this even just dealing with the minor versions of v2 and having to bump up dependencies just to ensure the build works. I have also seen one case where resolution order matters as Guava 15 was picked up before someone wanting 18 had an opportunity to request it and then methods were not available.

[cgruber]

So, #118 does an initial cut of this. Because javawriter is the .v3 fork that was always in Dagger 2, it's sort of pre-shaded. This doesn't shade guava, but most importantly shades auto-common, which we've seen collide with autovalue and autofactory in the wild.

I'd like to shade more of guava, but it'll have to wait until we stop using literals in the code-gen. I'm going to mark this closed, as the compiler jar is shaded, and we can re-open or open new issues as problems arise.