Allow PythonVenvOperator using other index url

[jscheffl]

This PR adds the option to specify extra index URLs to PythonVirtualEnvOperator (+corresponding decorator) in order to be able to install virtualenvs with (private) additional Python package repositories.

Besides the option to modify the worker config or adding ENVs to specify additional PIP install configs, this allows to use different back-ends per DAG/Task.

As the definition of (private) extra index URLs might require credentials to be passed, using plain requirements or pip install options would expose passwords as secrets in logs. Therefore the Airflow core provided connection types were extended to contain a "Package Index (Python)" connection type that can be used to store the credentials in Airflow in a (more) secret way and preventing to expose.

Summary of changes, separated by commit:

• Added a Package Index (Python) hook
• Extended PythonVirtualEnvOperator for extra index URL and caching

Note: The PR was based on a discussion in Slack in https://apache-airflow.slack.com/archives/CCPRP7943/p1684608779378759
Note (2): Caching of venvs was separated in a follow-up PR boschglobal#2

How and what to test:

• Pipeline green obviously
• Open the Web UI connections form and see that a new connection type "Package Index (Python)" is available (with proper form)
• Take a look to docs and check with a DAG, e.g. use example_python_operator and modify some parameters and try the new options
• Review the added RST docs

@AutomationDev85 @clellmann @wolfdn

[uranusjr]

I would prefer the changes are split into separate pull requests. The repository uses squash-merge and the separate commits would be lost in Git history.

[jscheffl]

I would prefer the changes are split into separate pull requests. The repository uses squash-merge and the separate commits would be lost in Git history.

Good idea @uranusjr , did not think about the squash. Splitted the ground work into #33051 - This PR branch is based on the other PR's branch (now). Change are only the two latter commits, the first both will go away if the other is merged.

[jscheffl]

I would prefer the changes are split into separate pull requests. The repository uses squash-merge and the separate commits would be lost in Git history.

@uranusjr Now the spin-off from the base rework is merged, this PR is reduced to the core feature of having a "Package Index" core hook/connection and the option to use this in VirtualEnv operators

[uranusjr]

One minor comment, overall looks good to me.

[potiuk]

Looks really goood. But I have a question about separating out BranchPythonVirtualenvOperator to a separate PR.