Add workflow that updates a vX.Y tag on release

[joerick]

This PR will automatically push an updated vMAJOR.MINOR tag for cibuildwheel. e.g. the tag v2.14 would point to version v2.14.2, until v2.14.3 comes out.

It's implemented using a fork of https://github.com/actions/publish-action , https://github.com/joerick/update-vX.Y-tag-action

Context from discord:

@henryiii:

I've resisted moving vX tags since cibuildwheel adds and removes platforms in minor releases, but what do you think about a moving vX.Y tag to reduce dependabot chatter on patch releases?
Dependabot won't update to a different number of .'s since April 2022, so it would be entirely opt-in.

[joerick]

Gonna merge this so i can test it in the upcoming release, hope that's okay with everyone.

[LecrisUT]

Why not move major tag as well?

About your action, how about enabling issues, making a top level action that calls 2 subactions (see cache action) that update the major and minor version respectively

[henryiii]

@henryiii:

I've resisted moving vX tags since cibuildwheel adds and removes platforms in minor releases, but what do you think about a moving vX.Y tag to reduce dependabot chatter on patch releases?
Dependabot won't update to a different number of .'s since April 2022, so it would be entirely opt-in.

Specifically, platforms change in v2.X releases, and a user should be aware of those upgrades. Adding a new python version or something like musllinux might break a workflow (probably right before release). Removing a platform (like old CPython) could cause wheels you expect to be there to not be there.

If you don't care about any of this, you might as well be fully unpinned.

[LecrisUT]

That makes sense. That should be documented in the README.md