Make super-tox official, use it in ops CI (and elsewhere!)

[james-garner-canonical]

What super-tox tries to do has a ton of overlap with what we're trying to do in Ops CI, including ongoing efforts such as canonical/operator#2317

Being able to do this with other charm libraries, and with libraries like pytest-jubilant and even jubilant itself would be amazing in terms of letting library authors develop with confidence that they're not breaking anyone.

It would be great if we could allocate some time to giving super-tox the love it needs to be able to fill this role. I'm imagining that we would want:

1. Patcher tool to patch a given dependency in a (local copy of a) (charm) repo with a user-specified version of the dependency (e.g. git branch, PyPI pre-release, local file), should take care of forcing Python version compatibility (if requested, or always?)
2. Runner tool to run a standard command runner environment (lint, unit, integration) and capture results in a standardised format (like Add machine-readable output option (JSON/CSV) #18), perhaps making assumptions about the tools under the hood (e.g. pytest) to provide more granular information (and gracefully providing less information if it's a tool we don't understand).
3. Analysis tool for comparing the output of of the runner tool (2) for the same (charm) repo and different dependency versions.
4. Super-tox-like tool for local use to handle running tools 1, 2 and 3 on large batches of charms (potentially including cloning repos, spinning up VMs (assume multipasss), etc).

We could then use the patcher, runner, and (optionally) analysis tools in CI -- the CI glue would be comparatively very simple.