Fix #6835 (instantiating a Hackage indefinite package with an inplace package doesn't work)

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Fixes the bug by accurately tracking when instantiations refer to
inplace packages, and adjusting previously non-inplace packages to be
inplace when this occurs.  See comment in ProjectPlanning.hs for more
details.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Cabal Init Omnibus

Replace List with NonEmpty in TargetsMap

Add regression test for #5782, which requires extending test harness to v2-install

Prefer canonicalized path when guessing tools from GHC path

Add 'preferred-versions' support for LocalIndexRepo 

Co-authored-by: maralorn <malte.brandy@maralorn.de>

Motivation
----------
Often times, the user facing `ghc` binary is
symlinked by other forces, such as the package manager,
tooling like ghcup etc. As such, the naming convention
(version suffix in particular) may not align with the
assumptions made in Cabal and it may find an incorrect ghc-pkg.

See:
  - https://github.com/haskell/cabal/issues/7390
  - ghc/ghc#18807
  - haskell/ghcup-hs#73

Solution
--------
Guessing the ghc-pkg path is already a hack and will be solved
more appropriately in the future, see
  - ghc/ghc!4214
  - ghc/ghc$2710
These patches will solve the issue for future GHC versions.

As such, this patch provides a workaround for
older, already existing GHC versions by first always
following the symbolic link of the ghc binary (if it is one)
and prefering its target directory as the guess lookup
location.

Rationale
---------
The canonicalized path of the ghc binary usually points to the
bin/ directory unpacked from a bindist, which is less likely to be
tampered with by distributions and tools. As such, prefering the
canoncialized path should get us more robust results.