Make Setup a separate component

Quoting from `Distribution.Client.ProjectPlanning.elaborateInstallPlan.elaborateSolverToComponents`:

> At this point in time, only non-Custom setup scripts are supported.
> Implementing per-component builds with Custom would require us to create a new `ElabSetup` type, and teach all of the code paths how to handle it.

And from `Distribution.Client.ProjectPlanning.setupHsScriptOptions`:

> TODO: Fix this so custom is a separate component. Custom can ALWAYS be a separate component!!!

So... what's at stake here? The problem is that packages with a custom setup (which currently includes `Custom` and `Hooks` build types) go through the "whole package" codepath in `cabal-install`, in that `elaborateSolverToComponents` returns a whole package instead of a collection of individual components. This is because `cabal-install` only has a half-baked notion of `Setup` as a separate component (e.g. we have `compComponentName :: Maybe ComponentName`, where `Nothing <=> setup`).

This means that packages which use those build types are locked out of certain newer features, such as multiple libraries.

Instead, we should make the setup a separate component, which other components in the package depend on. It would probably also be worth tackling #3984 while in this area, as otherwise we would get incorrect recompilation checking if the setup consists of more than one module.

I believe the core of an implementation would be to figure out how to populate the fields of `ElaboratedComponent` in `Distribution.Client.ProjectPlanning.elaborateInstallPlan` (see the `notImpl` function). Then remove the `cuz_buildtype` legacy fallback reason and try to build some packages with `Hooks` build-type (see the [`SetupHooks` overlay](https://gitlab.haskell.org/mpickering/hooks-setup-testing) for a repository of such packages).