Refactoring in preparation of #11411

[tdammers]

This commit includes a series of refactorings that are necessary to
solve #11411:

• Abstract the Rebuild monad into the MonadRebuild typeclass, introducing the withRunRebuildInIO method of MonadRebuild. This allows us to interleave plain IO with MonadRebuild without necessarily having to use Rebuild itself. This is especially important because Rebuild also encodes the "current working directory" concern, which is relevant within cabal-install, but something we don't want to require within the Cabal library. Since the MonadRebuild typeclass allows for arbitrary custom monadic state per instance, it can live in the Cabal subproject, together with operations defined in terms of the typeclass, while Rebuild itself remains in cabal-install, using the custom monadic state to cover the "current working directory" concern.
• Change the StateT part of Rebuild into WriterT, since we only ever emit additional files from within a Rebuild context; consuming them happens on the outside, so Writer is sufficient.
• Provide MonadRebuild instances for the existing Rebuild type, and for the most minimal type that can satisfy the typeclass, WriterT [MonitorFilePath] IO.
• Implement most file monitoring / Rebuild actions in terms of MonadRebuild, so they can live in Cabal (Distribution.Simple.RebuildMonad), leaving only cabal-install specific things in the existing cabal-install module (Distribution.Client.RebuildMonad). Specifically, we implement rerunIfChanged' in terms of MonadRebuild and a custom function for chaining IO actions (serially or in parallel, as needed); the existing rerunIfChanged and rerunConcurrentlyIfChanged functions, which live in cabal-install, are now implemented in terms of rerunIfChanged', which lives in Cabal).
• Move large parts of the Distribution.Client.FileMonitor module from cabal-install to Cabal (as Distribution.Simple.FileMonitor); we will be needing these parts to solve Build tool not rerun when build tool version changes #11411 (Distribution.Client.FileMonitor still re-exports all of them though).
• Move most of the Distribution.Client.HashValue module over to Cabal (with the exception of TUF-related functions, which are specific to cabal-install; again we re-export everything in cabal-install to maintain API compatibility).
• Move getFilePathRootDirectory from Distribution.Client.Glob into Distribution.Simple.FileMonitor.Types - it has little to do with actual globs, and is only used for file monitoring purposes.
• Shuffle some utility functions around to make them accessible where we need them.

The big picture with all this is that we want to reuse the existing file monitoring machinery to keep track of build-tool versions alongside generated source files. However, the tracking needs to happen in the Cabal library, while file monitoring has so far only been available in cabal-install; hence we need to move the required file monitoring code and its dependencies into the Cabal library, but without introducing any cabal-install specific concerns into Cabal, and without breaking API compatibility on the cabal-install side.

QA Notes

This PR should not cause any observable changes to existing code, but it does expose some things via the Cabal library that were previously part of cabal-install. Specifically, file monitoring, the glob API, and hash functions are now available as part of the Cabal library API, and can be used e.g. in setup hooks.

---

• 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!)

[Bodigrim]

Cabal cannot depend on non-boot libraries.