Add hpack command line option

[scott-fleischman]

Resolves #3179.

• Any changes that could be relevant to users have been recorded in the ChangeLog.md
• The documentation has been updated, if necessary.

I tested it with the --with-hpack option and without, and it works as I intended. I couldn't think of a good way to test this in code, so I did not add any tests to the test suite.

Details

The core change is pretty basic.

• I added an HpackExecutable type with two cases--one for the bundled hpack, and one with the hpack command.
• I added HpackExecutable as a field to the GlobalOpts and BuildConfig types.
• I used runCmd to execute the command, which requires an EnvOverride to create a Cmd value.
• Then the remaining effort was in propagating the necessary information to the hpack function.
  • When HasEnvConfig was available, I used the hpackExecutableL lens to retrieve the HpackExecutable
  • Else I passed HpackExecutable and EnvOverride as needed as function arguments.

[mgsloan]

LGTM! I think it probably makes sense to also support this as a configuration option, similarly to with-gcc:. This way you can just stick it in your config.yaml to easily change hpack version globally. Do you want to add that to this PR? If not, that's fine, this looks great to me otherwise, ready to merge.

[scott-fleischman]

@mgsloan I updated the PR based on your suggestion. And thanks too! That radically simplifies the code, since all code paths to hpack had HasConfig env, so I was able to avoid all of the extra argument passing. I was able to add a couple simple tests to verify that the configuration option is parsed correctly.

One question is whether it's ok that the hpack output is simply inherited. A typical run looks like:

$ stack build --with-hpack=hpack
generated testhp.cabal
testhp.cabal is up-to-date
testhp.cabal is up-to-date
testhp.cabal is up-to-date
testhp.cabal is up-to-date
testhp.cabal is up-to-date
testhp-0.1.0.0: configure (exe)
Configuring testhp-0.1.0.0...
testhp-0.1.0.0: build (exe)
Preprocessing executable 'testhp' for testhp-0.1.0.0...
testhp-0.1.0.0: copy/register
...

Also, it's surprising that the hpack function gets called 6 times as part of a stack build! And it apparently gets called twice as part of a stack clean. Is that expected?

[scott-fleischman]

Ok I see that the multiple hpack invocations are addressed in #3382

[mgsloan]

LGTM, thanks!