Scope IjModule COMPILED_SHADOW library dep to the 'compile' scope.

Created by: strangemonad

related to https://github.com/facebook/buck/pull/478

Note: this patch is a sketch of an approach and actually introduces a regression to the correctness of 'provided_deps'. See the last comment as we figure out the correct approach.

Summary: a java_library IJModule's exported_deps become dependency graph nodes of type COMPILED_SHADOW and are then included in the IJModule as a 'provided' library rather than a 'compile' library.

It's unclear how IJ would ever get that provided dep on its classpath. An example of a 'provided' dep would be acrypto provide like Bouncy castle that's installed into the jdk on the machine and automatically included in the classpath of the jvm or slf4j that's included at runtime via another lib.

Here's an example to make it more concrete. Consider the following buck dependency chain:

my_app:java_binary -> my_lib:java_library -> my_lib_compiled_java_protos:java_libary -> my_lib_java_protos:genrule

In this setup, my_lib.exported_deps = [':my_lib_compiled_java_protos'] where the leaf library is a buck 'java_library' in the module graph that was built simply by defining a 'java_library' who's sources are the java files output by protoc in the ':my_lib_java_protos' target.

By the time AbstractIjLibrary#addAsDependency is reached, we fall into the if (dependencyType.equals(IjModuleGraph.DependencyType.COMPILED_SHADOW)) branch which calls IjDependencyListBuilder#addCompiledShadow (its only caller).

Additionally, I think there might be 2 other bugs hiding in here

1. we unconditionally add the lib as 'exported', this should depend on whether the compiled shadow lib was included in 'deps' or 'exported_deps'

2. We should properly handle 'provided_deps' for both COMPILED_SHADOW and PROD/TEST types as well. This patch breaks the first but the later dep types are always included as 'compile'.