refactor(venv): use ensurepip and common methods

[gastmaier]

There is no guarantee pip is installed in the host to inherit to the
virtual environment. It is a bad practice to use host pip without
upgrading since it will be out-of-date.
The rationale behind the command is described at:
https://peps.python.org/pep-0453/

ensurepip --upgrade is not used because it ensures pip is at least as
recent as the one available in ensurepip, not the latest released.
Instead, upgrade explicitly with pip.

The method run_python_venv_creation was added to remove the repeated
venv creation logic.

Also loosely fix for windows (checked paths only), but tests should run on windows if we want to (pretend) to support (for unknown reasons).

Removed:

• get_venv_pip_path: invoked vevn's pip directly. Despite functional, for all other logic we require invoke as venv/bin/python -m, it was a weird exception.

Tests:

• test_venv_python_has_virtual_env_set: check in accordance to https://docs.python.org/3/library/sys.html#sys.base_prefix

Notes:

This pr does not investigate doc_manager, I touched it solely to move on with the venv refactor.
I believe there is a need for true venv generics, there is an assumption that venv is only for the documentation but there are many handy tools on it across the sdks.

[joabech]

Thanks, this looks like a good improvement. I'll run a few tests, then I'll merge if I see nothing strange.

there is an assumption that venv is only for the documentation but there are many handy tools on it across the sdks.

No, that's not the case, but it's only the docs that automatically creates and runs the venv. Like you implied, we use various Python script in our builds for a lot of other things as well. In hindsight and although this is neat from user point of view, I think the way of doing this auto install/enable should've been done in another way. But, I live the clean-up you've done, thanks!

[joabech]

I've tested this out in a few scenarios now and it's all good, thanks, this is a great improvement. Merging!