Kythe extractor support

Now the `ghckythe-wrapper` can be used in place of the `ghc` command to emit artifacts, which is fine for local, non-isolated indexing.

The more proper way would be to add [extractors](https://kythe.io/docs/kythe-overview.html#_what_kythe_requires) for the build systems (here Stack, Cabal build, Cabal new-build, ...) that save all the required inputs in [index packs](https://kythe.io/docs/kythe-index-pack.html), so the separate indexing phase can happen exclusively based on the *hermetic* index pack data.

This would make it possible to do reproducible and/or distributed indexing.

The main tasks are:

##### 1. Identifying (per build system) how to track down all the arguments and resource dependencies needed for the build.

This is not always trivial, as the deps need to capture auto-generated inputs etc too.

There's also the question of system-level dependencies (like global shared libraries) - should these be assumed omni-present on both the extractor and the indexer machines? Should they be added to the index pack?

##### 2. Generic support for operations (reading/writing) index packs.

##### 3. Making the haskell-indexer work out of the index pack.

How should one use the index pack's content?

The naive solution is to unpack the deps needed by the ComplilationUnit to some local place, and working from there. Attention has to be paid that the build is isolated, and GHC doesn't pick up unexpected dependencies.

The more desired solution is to make the indexer (and so GHC) pull the dependencies on-demand from the index pack (instead of prefetching and extracting). This has the benefit that in case of over-eager extractors (that include more resources in the pack than strictly needed) it's still only the needed data that's pulled.

+ @creachadair