Implement new haskell-updates workflow

[sternenseemann]

For the discussion that led to this, see #354270.

I think an uncontroversial way forward would be to do the following going forward:

• Base haskell-updates PRs on master for fast testing on Hydra.
• Merge haskell-updates into staging as a general rule. When staging-next is in an early phase we can consider merging it into staging-next on a case per case basis.

Outstanding tasks to make this happen (not sure if this is exhaustive?!):

• Finish haskellPackages: update stackage and hackage #354270 and the following staging-next rotation. Unfortunately, the PR is currently based on staging.
• Update the maintainer documentation, i.e. HACKING.md.
• Update the merge-and-open-pr.sh maintainer script
• Update periodic-merge-24h.yml to merge the merge base of staging and master into haskell-updates to prevent haskell-updates from being ahead of staging. This should be possible with GitHub action's outputs from jobs, but I don't know how it'd precisely work.

cc @NixOS/haskell @vcunat @K900

[maralorn]

I am in favor!

[mpscholten]

In the other thread you suggested getting rid of shellsheck:

Clamp down on the use of writeShellApplication in nixpkgs. Executing shellcheck can be done in passthru.tests for nixpkgs, so I don't really see why it needs to be used in this way, it currently is. Even without the unfortunate situation with haskell-updates, this would reduce rebuild time for a lot of packages probably.

Given this would reduce rebuild time for a lot of packages probably, why was this idea discarded?

[sternenseemann]

It's not a permanent solution, as it would mean enforcing some kind of dependency discipline in nixpkgs. There's really nothing to prevent other projects from depending on Haskell packages. It would be silly if we had to disable e.g. documentation generated using pandoc just so that we can keep merging haskell-updates into master.

[sternenseemann]

#367709