[RFC] Cabal plugin infrastructure

This is a WIP. Fendor & I will edit this description to refine the features & requirements.

## Inspirations

* git
* cargo

## Reasoning

To avoid bloat in `cabal-install` CLI and offer a more ergonomic way to use plugins, we must offer first-class support for cabal CLI plugins.

* `cabal why-depends` (https://github.com/haskell-hvr/cabal-plan/pull/53)
* `cabal status` (#7500)

More importantly, it allows us to provide features in "beta" or "experimental" status to our users before integrating them into the CLI codebase when they are more mature.
This is a low-tech solution but tech is not the only aspect being considered here.

## What we need

* Plugin infrastructure for `cabal` CLI
* cabal instal --plugin
* It is installed in ~/.cabal/bin XOR ~/.cabal/plugins/bin
* When people type `cabal foo`, if `foo` is not a valid subcommand, we lookup `cabal-foo` in the bin directory.
* Provide a `cabal-metadata` package as companion tooling for plugin authors
* Provide structure representation of the plan.json & build-info.json
* Handle incompatibilities between Cabal versions. Need more thought.
* JSON incompatibilities
* Binary incompatibilities

* Cabal version compatibility
* One plugin version per project?
* One plugin version per installed ghc.
* Call ghcup directly to install cabal plugins. Symlink logic is reused, the same as HLS

* Cabal command-line arguments passing
* This amounts to calling another binary with the parameters passed. Do we want to setup some stuff on the cabal-install side (like environment variables) before calling the binary (cabal-foo in ~/.cabal/bin)?

cc @fendor

Start by refining the requirements in this RFC, especially plugin discovery and installation for the cabal CLI. Review the proposed cabal-metadata companion package and the plan.json/build-info.json compatibility concerns. Done means the plugin model, version compatibility, argument passing, and installation behavior have agreed requirements.

Written by the indexing model from the issue text.