Draft: Use Hpack

[cprecioso]

Related to #2718

HPack has a saner glob syntax than regular Cabal. Makes it simpler in general, and also better able to remove node_modules from the data folder.

[Martinsos]

@cprecioso interesting! I always liked package.yaml from Stack more than the .cabal format, due to more stuff being done automatically, but I remember last time I was considering this there was a reason why I decided it doesn't make sense to go for it. I can't remember what it is at the moment -> maybe that changed, whatever it was, or maybe I overestimated some complexity that is not there. Or maybe the reason is still there. I will take a look and give this a thought for sure (when I catch some time).

[Martinsos]

I took a look, it looks good! My main concerns are:

1. That something that we need from cabal won't be properly supported and we are in trouble then.
2. That this will complicate our usage with extra layer of abstraction.

For (2), I am not making that up: I was there, using package.yaml because I was Stack user which comes with package.yaml, and I liked it but it was easier just dealing with cabal directly, because I didn't have to figure out what is some option doing in package.yaml and how it maps to cabal.

On the other hand, I do like a lot that we don't have to list every source file, that is really annoying and makes refactoring harder.

It is also nice that we have less work specifying data files, although that changes less often and is maybe a bit less of a trouble.

I would suggest following: {lease investigate a bit if we can fall into some obvious trouble for using hpack. Maybe check out open issues on their Github, see if any are concerning.

If that is looking fine, I would say let's give it a try, see where it takes us. We can revert back to cabal if need be.

[Martinsos]

It is nice if we don't have to list all the file extensions anymore!

It does seem though that these paths are currently too aggressive -> they will pick up everything from the Generator if I am right, not just Generatore/templates? Similar for CLI? And we still have to explicitly include dot files hm.
Let's fix this for sure, so they are targeted correctly.

As for packages// -> I am slightly temtped to name them by name here, each one, so that if we change some structure in packages, it is still picking up correct stuff. But maybe that is too much.

Hah I am now becoming cabal person, liking the explicity better :D. But here we can at least choose I guess, while in cabal it was forced, which was annoying for sure.

[Martinsos]

Is this potentially a problem sol/hpack#569 -> mentions that it doesn't enable merging ghc-options, I didn't yet completely figure out what that means though.