Update release process for providers to include mixed RC versions

[potiuk]

This PR updates released process for providers to enable releasing providers in more regular batches. Sometimes when we exclude a provider from previous voting, we want to release RCN (2,3 etc.) candidate.

However, especially when time between previous RC and the new one is long (for example because fixing took a long time) we might want to release the RCN release for that cancelled providers and RC1 for all the providers that have been changed in the meantime.

This cchange makes it possible (and easy):

1. release RC1 for all providers (the RCN provider should be skipped,
   because tag for this provider already exists.

2. release the RCN providers with --version-suffix-for-pypi rcN.

The release process and tools were updated to account for that - where rc candidate number is retrieved from packages prepared in dist.

Fixed a few small missing things in the process.

---

^ 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]

BTW. This is just intermediate step. After #36391 and this one, I will add one more change where I will automatically bump RC versions for providers that need RCN. This will make our process quite a bit more robust as we will not have to remember if we removed provider from the past wave or not - it should properly assess which RCN version we should prepare for each provider and we could simply remove the --suffix flag.