Meta: Exact-printer Mega-issue

# What is this issue?

A central place to discuss the issue of a Cabal exact-printer so that we can push forward the work all in one place. Currently, The discussion stretches back across many issues over the past 6 years.

## What is it?

An *exact-printer*, as inspired by [`ghc-exactprint`](https://hackage.haskell.org/package/ghc-exactprint), is a byte-for-byte bidirectional parser and pretty printer, which gaurantees the following constructs exist and are principled:

- A `.cabal` file source tree representation, which is in bijection with the package description for a `.cabal` file for a given spec version. This representation should be parametrized with all offset and encoding information along with file data.
- A method for introducing deltas to `.cabal` file entries. I should able to update and transform individual components of data deep in the representation without modifying the broader structure.
- A pretty printer which adds offset annotations to the specification fragment so that the output should have a byte-for-byte round trip on no-op parse/print and print/parse tests.
- Tests which confirm this in `cabal-testsuite` and `cabal install`'s test suite for the individual commands.

## Why do we need it?

This work is tied very closely with the `format`, `init`, `gen-bounds` and other work as shown in historical discussions:

- https://github.com/haskell/cabal/issues/3614
- https://github.com/haskell/cabal/pull/6621
- https://github.com/haskell/cabal/issues/6187
- https://github.com/haskell/cabal/issues/4965
- [etc...](https://github.com/haskell/cabal/labels/exact-print)

This would free us up for several important quality of life improvements to the `cabal install` ecosystem, as well as general consumers of the `Cabal` library API. We would like to have this in by `Cabal-3.8.0.0`. The important bits this enables include:

- `cabal gen-bounds` - will be able to update `build-depends` stanzas in a principled manner, so that bounds management will be automatic in the future if the user so desires.
- `cabal format` - we hope that a `.cabal` format can have a canonical shape, so we can limit the amount of deviations from the norm, or ad-hoc formatting choices present in the ecosystem.
- `cabal init` becomes much easier to manage, and we no longer have to dedicate redundant types, formatting, and pretty printing to this effort.
- Transforming cabal files, with something like module discovery, becomes that much simpler.

## Who's in charge of this?

I am currently overseeing @ptkato who has been tasked with taking this on. Please consider him and myself a point of contact for this work, and join us in `libera.chat#hackage` to discuss.

@ptkato @gbaz @davean