How should we test cabal-install with internal libraries?

Convenience libraries (#3022) need some integration tests with cabal-install to make sure, e.g., cabal-install's dependency solver and builder can handle them correctly.

In the solver:
- [x] When public library depends on internal library, solver should know how to satisfy the internal library, and dependencies of internal library should be considered.
- [ ] Conversely, when public library does NOT depend on library, dependencies of internal library should only be considered if the buildable stanza associated with it (e.g., a test suite or executable) is being built.

Known bugs:
- [x] The dependency solver doesn't correctly interpret a build-depends on an internal library as referring to that library. (CC @edsko, @grayjay and @kosmikus in case you know why this is happening)
- [x] Installation into sandbox fails during ABI computation.
- [x] Regression: the component graph no longer respects build-tools.

Haddock:
- [ ] Does it work at all? Is the internal library known to Haddock? What does it display as?

Design changes?
- Maybe we shouldn't put things that are not package names in `build-depends`, otherwise the dependency solver has to work around them specially, since they never have any sort of valid version range. Alternatives are to have a special syntax for internal dependencies but keep them in build-depends (for example, a special "internal" version range).

No files or tests are named. Start by reviewing convenience libraries in #3022 and the cabal-install solver, builder, and Haddock entry points; then define integration coverage for internal-library dependency handling, conditional dependencies, installation, and documentation. Done means the unchecked behavior is tested and any design choice is resolved.

Written by the indexing model from the issue text.