Add support for "setup" components to target selector & new-build

[hvr]

Currently, we cannot refer to custom-setup components

See Distribution.Client.TargetSelector for currently supported syntax.

In order to reify custom-setup components in the target selector syntax, we'd have to introduce a new (singleton) namespace "setup", which has onlyat most a single inhabitant (hence a singleton -- however, this inhabitant only exists for build-type:custom packages), also named "setup". Consequently, this gives us the following ways to refer to the custom setup script for a package foo

• foo:setup (package-name : component-name)
• setup (component-name)
• setup:setup (namespace-name : component-name)
• foo:setup:setup (package-name : namespace-name : component-name )
• :pkg:foo:setup:setup (explicitly qualified package-name : namespace-name : component-name )

(Optional) Moreover, we could add the "filter" setups, which then gives us the ability to refer to custom-setups components of multiple packages via

• setups
• all:setups
• :all:setups
• foo:setups (trivial: all setup components in the package foo; IOW, same as foo:setup:setup)

This may be a pre-requisite for #4293 which needs the ability to cabal new-build setup(s) w/o building all remaining targets.

[ezyang]

In fact, we already have a concept for this, in Distribution.Solver.Types.ComponentDep:

-- | Component of a package.
data Component =
    ComponentLib
  | ComponentSubLib UnqualComponentName
  | ComponentFLib   UnqualComponentName
  | ComponentExe    UnqualComponentName
  | ComponentTest   UnqualComponentName
  | ComponentBench  UnqualComponentName
  | ComponentSetup
  deriving (Show, Eq, Ord, Generic)

So extending this idea further seems profitable.

[ezyang]

A prereq for doing this profitability is out-of-line custom setup build, i.e., a stripped down version of #4047