`install --lib` can create inconsistent environments when dependencies are involved

**Describe the bug**

`install --lib` can create inconsistent environments when packages are installed one by one (ie. when an environment is modified). This was fixed for the case of explicitly installed packages, but not for dependencies.

**To Reproduce**
Steps to reproduce the behavior:

`foo` depends on `bar`. Constraints simulate the evolution of the index.

```
$ cabal install --lib foo --constraint=bar==1
```

Now suppose a function `f` from `foo` returns/takes a type from `bar`. I install `bar` so I can interact with `f`:

```
$ cabal install --lib bar --constraint=bar==2
```

Poof, inconsistent environment. The two instances of `bar` don't match.
The second command succeeds because bar is not explicitly in the environment.

**Expected behavior**

One of

* failure when inconsistencies are detected
* failure when trying to update an environment (#8483)
* apply constraints from transitive dependencies from the exisitng environment, not only from top-level stuff
* rebuild the plan from scratch if necessary, like cabal-env does
* https://github.com/haskell/cabal/issues/6481#issuecomment-621011502
* https://github.com/haskell/cabal/issues/5559#issuecomment-557343257

**System information**

* NixOS 23.11
* GHC 9.4.8
* cabal 12223d7bf102d115d0d04097535f155f29dcd6b9

**Additional context**
Add any other context about the problem here.

* https://github.com/haskell/cabal/issues/8483
* https://github.com/haskell/cabal/issues/8483#issuecomment-1265457463
* https://github.com/haskell/cabal/issues/5559

Start by reproducing the two `cabal install --lib` commands with the `foo`/`bar` dependency and version constraints described here. Review issues #8483, #5559, and the linked discussion to determine which consistency behavior is intended; done means preventing or rejecting an environment containing incompatible `bar` instances.

Written by the indexing model from the issue text.