Bazel build files for inline-java

[Fuuzetsu]

This is a collection of build files that work with the given WORKSPACE
file. This should allow the user to run bazel test //... which will
build run all tests in inline-java: as of time of writing, this is
spec tests in inline-java and jvm-streaming.

• We're repeating ourselves a lot w.r.t. prebuilt dependencies. We
  need to have all the packages available to GHC at WORKSPACE level
  then we also need to know them at BUILD level. We can't just define
  them in WORKSPACE and refer to them from BUILD as WORKSPACE only
  works in current project: if user wants to use inline-java from
  another project, the WORKSPACE file here is irrelevant: indeed
  they'll have to define all these things in their own WORKSPACE.

---

Old PR description below. Note that nearly all points there have now been resolved due to better rules_haskell/rules_nixpkgs 🎊

This is a collection of build files that work with the given WORKSPACE
file. This should allow the user to run bazel run //:spec which will
build inline-java and run the spec tests.

• I'm using GHC 8.0.2 as I was unable to quickly find working 8.2.2
  set.
• We're taking open JDK header files from bazel but the libraries from
  nix. Neither exposes both:
  Consider exposing all files in a filegroup rules_nixpkgs#9
• We're repeating ourselves a lot w.r.t. prebuilt dependencies. We
  need to have all the packages available to GHC at WORKSPACE level
  then we also need to know them at BUILD level. We can't just define
  them in WORKSPACE and refer to them from BUILD as WORKSPACE only
  works in current project: if user wants to use inline-java from
  another project, the WORKSPACE file here is irrelevant: indeed
  they'll have to define all these things in their own WORKSPACE.
• rules_nixpkgs commit points at a temporary branch which includes
  changes from two outstanding PRs, both of which are needed to build
  inline-java
• spec target would be better as some haskell_test once that
  exists
• We're giving too many shared openjdk libs during build: we only need
  libjvm.so and maybe libjni.so but we don't have granular control
  over the filegroup so we end up using every shared lib in openjdk
  package which is not ideal.