Support Backpack

[mboes]

This should be fairly straightforward in the case of Bazel. The build is already component oriented, so there's no refactor required like for Cabal, cabal-install and Stack. Cabal supports a fairly elaborate "mixin linking" scheme, that we can simply drop for now. We don't lose expressive power, since everything that can be expressed as mixin linking can also be expressed using the equivalent of Cabal's signatures field, internal libraries and reexported-modules field (see #357). We just need to create (and name) more components (i.e. "rules" in Bazel parlance) than would otherwise be necessary, but that's fine.

So in short, AFAICT we need:

• Add a new rule attribute for libraries called signatures.
• Carry the set of signatures associated with targets in their respective providers. Use depsets for this, since signatures are inherited from one library to another.
• Implement module substitutions, as explained in the Backpack proposal. This means tacking on the correct [M=<M>] etc substitutions to unit id's and passing -instantiated-with arguments. This is explained here.
• Match modules and signatures before calling GHC.
• Detect when libraries remain uninstantiated (i.e. have unfilled signatures) after matching. In this case, we can't compile, but should type check and generate interface files (that is, we should pass -fno-code).
• Detect dependencies that are now fully instantiated after matching, and compile them.
• Import the Backpack tests found in Cabal's test suite and Bazelify them. This might require Support reexporting modules #357 and Support thinning and renaming modules #358 as prereqs for some of the tests.

We don't need package hashes like Cabal does, nor hashes of instantiations tacked on to hashed library names (eek!), because our package names are globally unique within the workspace.