feat: ensure Dockerfiles being up-to-date

[develop7]

Introduces linting workflow that makes sure generated Dockerfiles are up-to-date

[chreekat]

Awesome!

I'm curious, why do you pull the generator binary from a different workflow, rather than just use stack run in the same checkout that's being tested? .stack-work is being cached, so it's hard to say which choice would be faster. Plus, using the same checkout for testing means that it's easy to keep the generator and the dockerfiles in sync, doesn't it?

[develop7]

@chreekat because I seemingly cannot share artifacts between workflows and generator's cold build path takes too much time, which becomes a sudden obstacle for every innocent GHC upgrade PR by increasing build time to tens of minutes or so. Also artifacts have an expiry date, as well as actions cache items, so regular contributors would hit the "wait for the build the whole generator" wall every so often and we probably don't want that.

[chreekat]

Hm.. then I wonder if it would be better to make "build generator" and "lint Dockerfiles" separate jobs in the same workflow, rather than putting them in two separate workflows. It actually makes sense to me that workflow files should be based on events like "pr is opened" rather than having multiple workflows trigger for the same event.

The problem with pulling generator from a totally different place is that you're guaranteed to have incorrect results if you change generator in a PR and expect to see its changes reflected in the Dockerfiles, aren't you?

[develop7]

superseded by #181