Implement hpack-hash feature.

[simfleischman]

This implements the feature request in issue #380.

I used the name hpack-hash to make it clear that it is a hpack feature, not a cabal one.

I am happy to change the implementation and attribute name as needed.

[simonmichael]

Could you make it also suppress the hpack version, and anything that causes vcs conflicts. Cf #380

[arianvp]

Thanks so much for this! I've been pulling my hairs for hours why i couldn't build a specific stack.lock.yaml file anymore only to realise that my OS ships with a different version of hpack than stack ships with by default NixOS/nixpkgs#84820 (comment)

Not having the Hpack version in the generated cabal file seems to exactly solve that problem

[sol]

@simfleischman thanks for working on this!

• I agree that hashes in generated cabal files are a pain. In the past, there were sporadic complaints about stack overwriting modified cabal files, this is why @snoyberg eventually proposed modification detection by using hashes. This made sense at the time, but in retrospect I'm puzzled whether it hurt more people than it helped.

• From my perspective package.yaml is a definition for a Haskell package. With that perspective, I'm not sure if adding hpack-hash to package.yaml is a good fit. I opened Add command-line options --hash and --no-hash #390 as an alternative proposal. Everybody who cares about this, please try it and make sure that it solves your use case.

• I understand that the hpack version can lead to friction, but it also serves a purpose. Let's treat this as a separate story.

[simfleischman]

#390 meets this need