`pip install gmxapi` needs better handling when multiple GROMACS APIs are available.

This issue description is a work in progress. @eirrgang is still collating sub-issues from #4324 (closed), #4330 (closed), and external conversations.

Summary

There are several scenarios in which the gmxapi Python package that is installed may not be built against the GROMACS version that was intended.

• The Python packaging will need to be updated for #4334
• pip install gmxapi caches the "wheel" that it builds, which would get installed instead of a fresh build the next time that pip install gmxapi is run. The user can specify --no-cache-dir to build a new package for the currently detectable GROMACS dependencies, but this is an annoying imposition on our users, and we should be able to do better.
• The current advice for users to source GMXRC is not applicable in many cases. The documented alternatives involving multiple CMake options or environment variables allow for mismatched choices of fp-precision or MPI flavor that can go undetected.

Possible fixes

One or more of the following seem promising.

• The gmxapi Python package and its top-level module could be separated from its gmxapi._gmxapi C++ extension module, with distinguishing features that prevent inappropriate reuse. Additional logic in setup.py could dynamically choose the right dependency and manage a local build according to the detected environment.
• The Python package CMakeLists.txt could perform multiple (or at least more dynamically distinct) find_package() calls to find the GROMACS installations available, and to make sure that the user's pip invocation can be fulfilled unambiguously.
• GROMACS 2023 could install a pure-Python forward- and backward-compatible stub package for each library configuration. The user would choose which GROMACS flavor they want to build for by choosing a PYTHONPATH (rather than any of the previous methods of hinting pip). The distinct stub/config package would be dynamically set as a dependency of the built "wheel" so that the cached wheel would not see its dependencies satisfied in a subsequent invocation.
• Now that require Python 3.7+, we could try the new "stable" CPython ABI, and see if we can make the libgromacs-instance-specific parts of the gmxapi support part of the GROMACS installation, rather than specific to the user's Python environment.