cabal-install inconsistently looks through symlinks

`cabal-install` inconsistently looks through symlinks. Suppose for instance that one has a Cabal project in `/public/pkg` and that `public` is a symlink to `private`. Then, because `establishProjectBaseContext` canonicalizes paths, when building packages we will use source directories of the form `/private/pkg/srcdir`, but if we pass a dist dir of `/public/pkg/dist` (using `-builddir`) then we end up with a build directory of `public/pkg/dist`. That is, `srcdir` looked through symlinks, `builddir` did not. In such a situation, calls to `makeRelative` will fail to make the path relative, for example in `Distribution.Client.ProjectBuilding.rebuildPhase`.

In practice, this can mean that we pass absolute paths to GHC, e.g. for `-odir`, in cases where we previously passed relative paths. This might seem benign, but it could cause bugs; for example GHC will not respect the `-odir` flag if the paths to the source files it is given are absolute, as it will place build products next to the original files due to a logic of the form `odir replaceExtension srcFilePath "o"` (which will drop `odir` if the second argument is absolute).

**Task**: Calls to `canonicalizePath` in `cabal-install` should be audited and potentially replaced with `makeAbsolute`, or (even better) by keeping the filepaths relative wherever possible. This will be made much easier by #9718.

NB: I am **not** volunteering to carry out this task at this time.

Start with establishProjectBaseContext and the canonicalizePath calls in cabal-install, then inspect makeRelative and Distribution.Client.ProjectBuilding.rebuildPhase. Review #9718 for related context. Done means path handling is consistent for symlinked projects and does not unexpectedly produce absolute paths for GHC build options.

Written by the indexing model from the issue text.