The refactor in f70fc980 solved an
inconsistency in `buildAndInstallUnpackedPackage`. Namely, before the
refactor, we didn't pass `hsSetupBuildArgs` to the build invocations,
and afterwards we did.

The result is that build targets of (legacy) package `B`, that a package
`A` depends on, are now passed to the ./Setup build invocation of
package `B` (e.g. `./Setup build lib:openapi3` rather than just `./Setup
build`).

This means we no longer /build always all targets of a legacy-package/
(for example, the lib, the testsuites and the executables).
Instead only the required target (just the lib) will be built.

However, despite now passing the build args to `./Setup build`, we
weren't passing the same arguments to the `./Setup copy` invocation.
Therefore, `./Setup copy` would also try to copy targets of the package
that weren't built, resulting in a failure.

This fixes that failure by correctly passing the build targets to the
`./Setup copy` invocation, just like we do for the `./Setup build` one.

Fixes #9640

This change removes support for building sub-component targets in
cabal-install, since no versions of Cabal support this feature.

The test RunMainBad is also dropped because without the concept of a
file target, RunMainBad is the same test as ScriptBad.

This complements the previous commit in order to fix #9326

- This allows the use of several **API incompatible builds of the same
  version of GHC** without corrupting the cabal store.
- This relies on the "Project Unit Id" which is available since GHC
  9.8.1, older versions of GHC do not benefit from this change.

[fixes #8114]

In f70fc980, while refactoring
buildInplaceUnpackedPackage and buildAndInstallUnpackedPackage, we
started logging into a file on both cases, instead of logging to a file
only for buildAndInstallUnpackedPackage.

When building a package inplace, it is much more useful to be able to
see the GHC invocation directly outside of a log file.

This is especially relevant for Cabal developers working inplace.

Fixes #9606

This refactor of Distribution.Client.ProjectBuilding does the following:

* Moves package file monitoring logic to
  Distribution.Client.ProjectBuilding.PackageFileMonitor

* Moves the `buildInplaceUnpackedPackage` and
  `buildAndInstallUnpackedPackage` with auxiliary functions to
  Distribution.Client.ProjectBuilding.UnpackedPackage

* Refactors the common bits of `buildInplaceUnpackedPackage` and
  `buildAndInstallUnpackedPackage` to remove considerable code
  duplication while simplifying and making both functions more
  structured.

Namely, to better structure build inplace vs build and install, I've
introduced:

* `PackageBuildingPhase` describes the various phases of processing the
  unpacked package both inplace and on install
    * Configure
    * Build
    * Install (copy + register)
    * Test
    * Bench
    * Repl
    * Haddock

* Then, `buildAndRegisterUnpackedPackage` implements the common logic
  between the two functions (such as calls to ./Setup and the order of
  the phases) but delegates the logic specific to each phase to an
  argument function which maps `PackageBuildingPhase` to `IO` actions.

* Now, build inplace and build and install functions are comprised as:
    * A wrapper around `buildAndRegisterUnpackedPackage` which does
      things specific to each before and after the main phases are
      processed
    * A delegate function which maps an action to each package
      processing phase

Fixes #9499