chore: update the handling of uv dependabot updates

[moe-ad]

The changes made in #1401 did not work as expected, examples:

• build(uv): bump ghapi from 1.0.14 to 2.0.1 #1419
• build(uv): bump fastcore from 1.13.6 to 1.14.5 #1413
• build(uv): bump fastcore from 1.14.5 to 2.1.0 #1420

So in this PR, I am:

• Reverting the changes made in chore: ignore patch updates for uv package ecosystem #1401.
• Updating all the undesirable pyproject.toml changes that have been merged.
• Adding a job to ci_cd_dependabot.yml to add a note to the end of uv dependabot PR description so that we are reminded to verify any pyproject.toml changes in subsequent PRs before merging. The note will look like this. Already discussed this with @SMoraisAnsys as a fallback approach in the past.

We can also decide to stop worrying about restricting the bounds in the pyproject.toml altogether. We can then observe by how much the CI load would actually increase and then decide if we are fine with that.

[RobPasMue]

@moe-ad - watch out with #1419 ...

I had to change the behavior of the scripts to align with ghapi 2.X (which is not a patch update - it's a major bump!)

[RobPasMue]

Looking at your changes it doesn't seem to be reverted so I am fine with it

[SMoraisAnsys]

@moe-ad can you remind us what is the benefit of working with X.Y specificly ? When we discussed about that in the past, the goal was to reduce the number of PR opened by dependabot to lessen the load associated to CI bumps.
AFAIK this is working fine currently and allows us to update packages less often. The proposed changes are going to add an extra manual layer. Isn't that counter productive ?

[SMoraisAnsys]

Adding a request for changes review to ensure a response to my previous comment before any merge :)

[moe-ad]

@moe-ad can you remind us what is the benefit of working with X.Y specificly ? When we discussed about that in the past, the goal was to reduce the number of PR opened by dependabot to lessen the load associated to CI bumps. AFAIK this is working fine currently and allows us to update packages less often. The proposed changes are going to add an extra manual layer. Isn't that counter productive ?

Hi @SMoraisAnsys. If you read the PR description, I already made a comment about this:

We can also decide to stop worrying about restricting the bounds in the pyproject.toml altogether. We can then observe by how much the CI load would actually increase and then decide if we are fine with that.

FYI that this is the feedback that led to us taking this approach initially and I am personally fine with either approach (the manual step isn't much work and it doesn't happen often).

Though I must say that given that we do not yet know every possible way the ongoing effort to add more uv support might be impacted by the action dependencies, meaning we might require more iterations of the implementation in the future (overhaul how we are consuming dependencies for example), it might make sense to retain the flexibility pinning to major.minor in the pyproject.toml offers us.

[SMoraisAnsys]

As long as we keep using pinned dependencies and have a valid and secure way to update the dependencies on a regular base, I don't have any strong opinion. If you think that this won't add too much on your plate then you can test things and give us your feedback later.