Updated maven.gitlab-ci publish job to use CI_COMMIT_TAG for new version

Summary

Updated .gitlab-ci.yml to remove jobs that are no longer needed when run for a Java/Maven based project using release-it (configured in the project's .gitlab-ci.yml by including the release-it ci template) :

• include package-registry-push-snapshot job in pipeline to manually publish snapshot builds only a branch (not used with release-it)

• include package-registry-push job to only run in pipeline when $CI_COMMIT_TAG is present after release-it has run, using the value in $CI_COMMIT_TAG created by release-it as the new version for published artifacts (replacing the use of the .version job in the template)

• updated logic in .version job to determine the next version only for snapshots, and is only used if $CI_COMMIT_TAG is not set (additional logic now not used to be removed in future cleanups for the template)

• Addresses: https://gitlab.developers.cam.ac.uk/uis/devops/hr/wr/wrs-webapp/-/issues/174

Testing steps

Test by inspecting a project's pipeline that uses this version of the template, e.g. WRS MR https://gitlab.developers.cam.ac.uk/uis/devops/hr/wr/wrs-webapp/-/merge_requests/114

Confirm on a branch:

• the pipeline does not include a release-it job
• the pipeline includes package-registry-push-snapshot as a manual job, and when run, published a new SNAPSHOT and increments the version
• confirm the pipeline does not create a new tag, or update the CHANGELOG.md

Confirm on a merge to main:

• the pipeline now includes a release-it:release job, which creates a new tag, correctly incrementing the version, and updates the CHANGELOG.md automatically
• the pipeline does not include package-registry-push-snapshot
• package-registry-push now does not run in the pipeline for a merge (previous behaviour), now it runs in the pipeline for the tag, created by release-it
• in the tag pipeline,package-registry-push uses the same version as the tag created by release-it, and publishes artifacts to the Package Registry using this version

Reviewer checklist

The merge request reviewer should confirm all of the below items prior to merge:

• This MR addresses, or works towards addressing, the acceptance criteria of the linked issue,
• The scope of testing is adequate,
• The change has been tested,
• Documentation has been updated (changelog, README, guidebook if applicable)
• MR shows no new security vulnerabilities identified, or:
  • new vulnerabilities addressed as part of change, or
  • new issue(s) created to address vulnerabilities separately and linked to this MR, and
  • new Critical / High issues have been reviewed and this MR has been approved by a member of the Tech Lead Forum