Adjust limits when constructing cross-provider dependencies

[potiuk]

When we are constructing cross-provider dependencies, we should adjust
the limits to account for some apache-airflow packages that are not yet
released.

The adjustment is to add ".*" after the version number when
dependency is lower-bound with >=. It's not explicitly mentioned in
PEP 440 - it is only mentioned there that it works for
equality, but since >= is also part of equal it also
works there.

Example is a common-sql package that might be limited to >=1.1.0
in google provider as part of the change, but it might not yet be released
as it is being released together with the package it is needed by.

We need to adjust the version whenever in our providers we
refer to other providers with >= install clause because --pre
flag in pip only allows to install direct pre-release (and
development) dependencies but it does not modify requirements of
those package to also include pre-releases as transitive dependency.

Also, we need to remove the limits in devel dependencies because
the packages are not yet released at the moment we use those
dependencies, so the limits in devel should be removed, allowing
the developers to install Airflow without those devel packages.

Also a bug was found that would prevent to generate
the dependencies in case provider.yaml file only changed (bad
specification of .pre-commit include)

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

I deleted accidentally the branch in #25306 - but this one is refreshed @uranusjr - to reflect the finding from there. I added better description and explanation why we are adding .* and also test it in #24836

[potiuk]

It just mentions -pre behaviour as it is, without judging if it is a bug or not (because I do not know - it could be intentional or accidental behaviour which simply does not include our case when we need to install pre-release package which depends on specific version other pre-release package that has no released version yet).

[potiuk]

@uranusjr @eladkal -> now that the #25350 is green - I would like to merge this one first, so that it is separated from the "move' (I incorporated that one in the SQL move to test that it works).