Support an alternative to PIPAPI_PYTHON_LOCATION for configuring pip-api?

[woodruffw]

Right now, almost all of pip-api's state revolves around calls to pip, which in turn is located by pip-api by invoking it relative to the current interpreter (in effect {sys.executable} -m pip ...).

This works well 99% of the time, but it causes problems in one of pip-audit's expected installation patterns: being installed globally (e.g. via a system packager manager), but being asked to audit activated local virtual environments.

In that case, sys.executable points to the "global" Python interpreter (which itself might be indirect, like a pyenv shim), while the pip we want to target is pointed to by the $PATH (per the virtual environment). As a result, constants like pip_api.VERSION and all invocations of pip_api._call.call correspond to the "global" pip, not the one that the user might expect.

The PIPAPI_PYTHON_LOCATION environment variable notionally provides support for this, but using it correctly is not ergonomic: it needs to be set before pip_api is ever imported in order to affect constants like pip_api.VERSION.

I'm filing this mostly to think about it, since I'm not sure there's a "good" solution on pip-api's side 😅 -- the current behavior is arguably more correct since it aligns the installed pip_api package with whatever pip installed it, rather than whatever pip happens to have the highest priority in the $PATH.

Refs: pypa/pip-audit#450, pypa/pip-audit#455