No generated cabal files

[8n8]

Removes the cabal files that are generated from the package.yaml files.

[avh4]

Thanks for taking the time to open the PR, though I think I don't want to accept this for now, as detailed below.

My current evaluation:

The downsides of having the cabal files checked in:

• they can get out of sync. Contributors have to remember to re-run the build script before committing changes to the package.yaml files.

But the upsides are:

• my understanding is that this is the currently recommended best practice in the Haskell community, despite the downsides. See "Storing generated cabal files" for details.
• it removes the need to install hpack (and the correct version of it) to bootstrap the compilation environment:
  • some folks need to build elm-format from scratch (to support platforms without official binaries, or to make project-specific customization). Imo this is tedious enough in the first place, so I think it's useful to avoid any extra hurdles.
  • for 3rd-party package maintainers (most notably homebrew, but also nix, and, in the past, debian) the constraints of the package manager can often make source file generation steps tedious. Personally, I think the value of making things easier for downstream package maintainers is worth it over the annoyance of having to check in the generated files.

I'd be open to reconsidering, but this is a decision I'd want to be slow and careful about changing. Hopefully either cabal will eventually get better hpack integration, or some other feature to make hpack unnecessary (see Module listing discovery (wildcard glob) · Issue #5343 · haskell/cabal for relevant discussions) that will give a better solution than the current situation.

[8n8]

Thanks for taking the time to open the PR, though I think I don't want to accept this for now, as detailed below.

My current evaluation:

The downsides of having the cabal files checked in:

* they can get out of sync.  Contributors have to remember to re-run the build script before committing changes to the package.yaml files.

But the upsides are:

* my understanding is that this is the currently recommended best practice in the Haskell community, despite the downsides.  See "[Storing generated cabal files](https://www.fpcomplete.com/blog/storing-generated-cabal-files/)" for details.

* it removes the need to install hpack (and the correct version of it) to bootstrap the compilation environment:
  
  * some folks need to build elm-format from scratch (to support platforms without official binaries, or to make project-specific customization).  Imo this is tedious enough in the first place, so I think it's useful to avoid any extra hurdles.
  * for 3rd-party package maintainers (most notably homebrew, but also nix, and, in the past, debian) the constraints of the package manager can often make source file generation steps tedious. Personally, I think the value of making things easier for downstream package maintainers is worth it over the annoyance of having to check in the generated files.

I'd be open to reconsidering, but this is a decision I'd want to be slow and careful about changing. Hopefully either cabal will eventually get better hpack integration, or some other feature to make hpack unnecessary (see Module listing discovery (wildcard glob) · Issue #5343 · haskell/cabal for relevant discussions) that will give a better solution than the current situation.

Makes sense to me. I didn't know this before.