### What do you see as an issue?

I suggest supporting tabs in the docs to improve the readability when demonstrating different ways to achieve the same things.

**Motivation**
We have multiple ways to achieve the same thing in Airflow, for example:

- TaskFlow API & "classic" operators
- CLI & REST API & API client

However, our docs currently do not consistently demonstrate different ways to use Airflow. For example, https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html demonstrates TaskFlow operators in some examples and classic operators in other examples. All cases covered can be supported by both the TaskFlow & classic operators.

In the case of https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html, I think a nice solution to demonstrate both approaches would be to use tabs. That way somebody who prefers the TaskFlow API can view all TaskFlow examples, and somebody who prefers the classic operators (we should give those a better name) can view only those examples.

**Possible implementation**
There is a package [sphinx-tabs](https://github.com/executablebooks/sphinx-tabs) for this. For the example above, having https://sphinx-tabs.readthedocs.io/en/latest/#group-tabs would be great because it enables you to view all examples of one "style" with a single click.

### Solving the problem

Install https://github.com/executablebooks/sphinx-tabs with the docs.

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

"""
    Replace extra dependencies with provider package.
    The intention here is that when the provider is added as dependency of extra, there is no
    need to add the dependencies separately. This is not needed and even harmful, because in
    case of future versions of the provider, the dependencies might change, so hard-coding
    dependencies from the version that was available at the release time might cause dependency
    conflicts in the future.
    Say for example that you have salesforce provider with those deps:
    { 'salesforce': ['simple-salesforce>=1.0.0', 'tableauserverclient'] }
    Initially ['salesforce'] extra has those dependencies, and it works like that when you install
    it when INSTALL_PROVIDERS_FROM_SOURCES is set to `true` (during the development). However, when
    the production installation is used, The dependencies are changed:
    { 'salesforce': ['apache-airflow-providers-salesforce'] }
    And then, 'apache-airflow-providers-salesforce' package has those 'install_requires' dependencies:
            ['simple-salesforce>=1.0.0', 'tableauserverclient']
    So transitively 'salesforce' extra has all the dependencies it needs and in case the provider
    changes its dependencies, they will transitively change as well.
    In the constraint mechanism we save both - provider versions and its dependencies
    version, which means that installation using constraints is repeatable.
    For K8s and Celery which are both "Core executors" and "Providers" we have to
    add the base dependencies to core as well, in order to mitigate problems where
    newer version of provider will have less strict limits. This should be done for both
    extras and their deprecated aliases. This is not a full protection however, the way