Add hpack as a built-tool so it could be invoked to get a cabal file

[qrilka]

This and #39 give better integration with packages using hpack.
This PR requires input-output-hk/haskell.nix#80

[rvl]

I have run this branch and it successfully adds hsPkgs.buildPackages.hpack as a built-tools dependency.

Adding hpack as a build dependency could probably also be done entirely in haskell.nix, but it would be more complicated.

[angerman]

I'm a bit on the fence wrt to this PR. It starts opening the gate to the package modification that cabal2nix already does.

I assume we want to use hpack if if the generator is set to hpack in the package. Why can't we just refer to ${pkgs.buildPackages.hpack}/bin/hpack in the builder?

The issue right now (which doesn't really sit well with me) is:

1. We have an package.yaml file.
2. We run hpack to generate the corresponding .cabal file.
3. Now we inject hpack as a dependency into the cabal expression. But at this point we are far beyond the point where we actually need hpack.
4. We now translate a cabal expression into a nix-expression, but really we are generating something that's not a cabal to nix translation anymore.

[qrilka]

@angerman what do you think would be a better way here? Including generated file into a Nix expression maybe? That way we couldl have the same file for generating a Nix file and when building it.

[angerman]

@qrilka I would assume that hpack is deterministic. And running hpack during the build is fine. I'm just not very happy with the idea of jamming hpack into the nix expression that was generated from a cabal file. Maybe the comments in input-output-hk/haskell.nix#80 make more sense of how this could be solved without changing nix-tools.

[angerman]

I think this should be solved in input-output-hk/haskell.nix (See input-output-hk/haskell.nix#80) rather than here in nix-tools.

[qrilka]

Closed in favor of input-output-hk/haskell.nix#82