Defer merging of common stanzas

[leana8959]

This is the second part of the exact print parser. We changed the parser so that it doesn't merge the common stanzas during the parsing stage.

Depends on #11285 to update the test suite (after which the diff will be significantly smaller).

Background

Common stanzas are merged into their corresponding section during the parsing stage. This merging process doesn't retain the definition of the imports (i.e. common <name> ...) nor where they are used (import: <name>). To achieve exact printing and to be able to programmatically update the import list, we need to retain this information.

This PR is to remedy exactly that by deferring the merging process.

Implementation

We insert a new field gpdCommonStanza :: Map ImportName (CondTree ConfVar [Dependency] BuildInfo) in the GenericPackageDescription data type to track all the defined common stanzas. The merging is run only when the new accessors are called on a GenericPackageDescription.
We also added a bidirectional PatternSynonym that uses the old record syntax. The impact on existing code should be very low. Comparing against my PR to update the test suite is promising leana8959/cabal@accessor-tests...leana8959:cabal:no-flatten-package-description.

Please let me know your thoughts :)

---

Checklist below:

This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[leana8959]

Here are the benchmark results by timing the ./validate --partial-hackage-tests test.

• baseline (master branch)

  $ hyperfine --setup "./validate.sh" "./validate.sh --partial-hackage-tests"
  Benchmark 1: ./validate.sh --partial-hackage-tests
    Time (mean ± σ):     224.440 s ±  5.713 s    [User: 191.896 s, System: 34.800 s]
    Range (min … max):   218.596 s … 239.915 s    10 runs
  

• no-flatten-package-description

  $ hyperfine --setup "./validate.sh" "./validate.sh --partial-hackage-tests"
  Benchmark 1: ./validate.sh --partial-hackage-tests
    Time (mean ± σ):     232.745 s ± 10.650 s    [User: 194.793 s, System: 38.621 s]
    Range (min … max):   220.815 s … 254.096 s    10 runs
  

[ulysses4ever]

I'm not sure why validate is used for benchmarking parser changes. Validate is likely dominated by completely unrelated factors (e. g. solver). Would it be possible to just download a bunch of cabal files from Hackage (see clc-stackage for a curated set of packages) and run only the parser on them?