Contained "global" environments

When using IHaskell users should be able to install packages in a pseudo-global environment without potentially nuking the entire cabal setup. Package envs get us part of the way there but they still install things into the "global" cabal store (not sure if that's a bad thing but I found that this easily gets inconsistent after installing a couple of packages). As a workaround I was planning on suggesting that users:
* change the CABAL_DIR to some "sandbox" path.
* Install packages with `--lib acme --package-env local-env`
* Install the IHaskell binary
* The point GHC environment to `local-env`
* Now in a notebook (which is outside of the context of a cabal file or cabal init'd directory) you can simply do `cabal install --lib vector` and not affect the rest of your ghc setup.

The whole process is detailed [here](https://docs.google.com/document/d/1s8lwFOtX2FnYqNsGstkrotO8quDUPAZ32SN2zzZZysc/edit?tab=t.0).

This is essentially like making a python virtual env. This typically isn't an issue for Haskell packages since they can make their own walled context but IHaskell has a pretty tricky interaction with the GHC API that necessitates something like this.

This sort of used to be possible with cabal but according to @vaibhavsagar [this has been broken for the last few cabal/GHC releases.](https://github.com/IHaskell/IHaskell/issues/1591)

Would be great to get a way to support something like this through a formal, backwards compatible channel.

I'm not sure what came of issue #6481 but it sort of sounds like it would be useful for this case.

Start by reading the linked IHaskell workflow and the discussion in issues #1591 and #6481, then trace how CABAL_DIR, package environments, and the GHC environment interact outside a Cabal project. Done would mean a documented, formal, backwards-compatible way to create an isolated pseudo-global environment without destabilizing the user's existing Cabal setup.

Written by the indexing model from the issue text.