[gz-*] Rename gz-* ports

[talregev]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[dg0yt]

In the past, we had

• smooth transitions when we upgraded the old names to empty ports which depend on the new name before eventually removing them (example: proj4 -> proj) and
• users stumbling when we immediately removed the old name when add the new name (example: szip -> libaec, cf. [libaec] Build error on x64-windows #43846 et al.).

Just saying.

[talregev]

In the past, we had

• smooth transitions when we upgraded the old names to empty ports which depend on the new name before eventually removing them (example: proj4 -> proj) and
• users stumbling when we immediately removed the old name when add the new name (example: szip -> libaec, cf. [libaec] Build error on x64-windows #43846 et al.).

Just saying.

Thank you for the info. That good practice.
Before I do that, I want to see if I can rename the ports in the first place.
There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name).
Do you an idea how to solve that?

[talregev]

Thank you for the info. That good practice. Before I do that, I want to see if I can rename the ports in the first place. There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name). Do you an idea how to solve that?

@traversaro Can you help too?

[dg0yt]

Before I do that, I want to see if I can rename the ports in the first place.

You can do that. CI won't complain because it starts from scratch. But classic mode users start with the old ports installed.

There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name).

No 100% clear what you mean. But the proposed smooth approach would keep <name><number> in addition to <name>.

[traversaro]

Thank you for the info. That good practice. Before I do that, I want to see if I can rename the ports in the first place. There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name). Do you an idea how to solve that?

@traversaro Can you help too?

I am not sure I get what you meant with " There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name)."

[talregev]

Sorry I didn't been clear.
From @traversaro comment:
#43265 (comment)

Gazebo packages installing with the package name with the major version. Since I rename the ports as @traversaro suggested:

I think it make perfect sense to drop all the version number suffixes and just package the latest major version of each gz library.

Clearly I didn't do the correct changes, and ci is fail due that it not find the package name with the major version.
My question how to make this refactor in a smooth approach?

[talregev]

I figure it out.

[talregev]

I bring back old ports as @dg0yt suggested:

smooth transitions when we upgraded the old names to empty ports which depend on the new name before eventually removing them