Restructure scala provider, add JavaProvider (bazelbuild#227)

* Restructure scala provider, add JavaProvider

The key change is that the scala provider has been completely
restructured to match the structure of the JavaProvider. It no longer
tracks exports separately but instead has the following fields:

* outputs = contains all the outputs generated by the current rule
(nothing or ijar and class_jar); however, no rules here actually use it.

* compile_jars = contains all the jars dependent rules should compile
with. Thus, ijar and exports.compile_jars

* transitive_runtime_jars = contains all the jars needed to handle this
target at runtime. Thus, class_jar plus (deps + exports +
runtime_deps).transitive_runtime_jars

The created java provider (used by dependent native java rules) uses
just compile_jars and transitive_runtime_jars.

In general, this change was seamless. The major exception is if you were
specifically relying on only exports being re-exported by specifically
gen_scrooge_srcjar. Beforehand, any jars produced by direct dependencies
were not being exported to dependents but now they are. Note that, if
you were using scrooge_scala_library instead, nothing should change.

Other changes:
* Use depset instead of set. (set docs already say set should be
considered deprecated and just points to depset anyway)

* Tests amended to exploit that JavaProvider is properly constructed.
Note that things are still a little strange until Bazel releases
incorporate some fixes to JavaProvider and native provider rules.
Generally, only deps for java_library and java_binary work at the
moment.

* Using JavaProvider, requires Bazel 0.5.2

Remove scala_exports_to_java
Prefer using JavaProvider over scala provider
  (can probably avoid using scala provider completely?)

* update minimum bazel version to 0.5.2

.travis.yml

@@ -12,7 +12,7 @@ os:
 
 env:
   - V=HEAD
-  - V=0.4.5
+  - V=0.5.2
 
 before_install:
   - |