Add CI dogfood test; only Windows for this PR

[Mikolaj]

A part of the effort to prevent hiccups like #7649.

I've tested that it fails with 3.6, works after reverting the offending autoconf PR, once the new CI jobs are merged, I will test if the new autoconf fix passes with it.

I've also fixed some details in he previous CI jobs from the workflow and bumped cabal used for bootstrapping from 3.2 to 3.4 in order to make list-bin available, needed for the dogfooding jobs.

Citing IRC:

I will build master, wipe out store, build master again using the exe just obtained
this is an automatic replication of the test with which @jneira originally detected #7649
let's see if that's longer than current CIs
(that was Tamar's reservation about this idea, I think)

our windows.yml CI workflow builds network as part of all cabal deps (and cabal source itself), but it uses cabal 3.2.0.0 to do so
it takes 21m to do so (BTW, the script a bit broken, the --only-dependencies part is vacuus, strangelyl)
while the whole workflow takes 50min or more
so the dog-fooding workflow would be faster than some of our existing workflows
so, if run concurrently (not always the case), it would not increase the waiting time
(that's with GHC 8.10)

doh, I've just looked at the corresponding linux and macos CI script templates and the validate.sh script they run instead of the simple Windows commands and I have no idea what's going on there
in particular, I'm not going to amend them in this commit; on the bright side, perhaps they do test dogfooding, given how smart they look
[edit: actually, they probably don't, but they have autoconf tests that seem to catch at least some of autoconf-related breakage that doesn't break Windows CI]

strangely network seems to compile fine in CI with GHC 8.6.5
I also learned what the famed zinza is for --- it's for generating CI scripts from template

[jneira]

I think the script could be simplified using a matrix of ghc versions.
It could be a separate job which can use the cabal built in the actual one via upload/download artifacts

But those things can be done in new prs after this
Thanks!

[Mikolaj]

I think the script could be simplified using a matrix of ghc versions.
It could be a separate job which can use the cabal built in the actual one via upload/download artifacts

But those things can be done in new prs after this

Yep, fully agreed, there is even a ticket about a part of what you said (#7655). :)

Edit: Also, we should have dogfooding for linux and macos as well, more than 2 GHCs tested for Windows and macos, script generating code moved out of the common code base and generally the CI needs a lot of work.

[Mikolaj]

@Mergifyio backport 3.6

[mergify]

Command backport 3.6: failure

No backport have been created
GitHub App like Mergify are not allowed to create pull request where .github/workflows is changed.

[Mikolaj]

This has been backported to 3.6 via a direct push to the branch.