feat: allow use of consistent container tagging

[wilsonjord]

Motivating ticket: https://github.com/GeoNet/tickets/issues/14398

This PR adds a composite action providing a consistent tag, or at least, consistent outputs to construct such a tag.
This should be suitable for use in the reusable workflows, as well as explicitly within users own workflow jobs.

Currently, the proposed format is commit sha-timestamp-build id...for example, 1da9c71-20240515111413-9094587538

Points to consider are:

• order of fields
• need for timestamp (which was part of my original work to better ensure "uniqueness", but may not be required in presence of build id
• any other missing fields

[ardrigh]

Currently, the proposed format is commit sha-timestamp-build id...for example, 1da9c71-20240515111413-9094587538

Points to consider are:

* order of fields 
* need for timestamp (which was part of my original work to better ensure "uniqueness", but may not be required in presence of build id
* any other missing fields

I would recommend putting the date timestamp field first, adding git to the front of the SHA as is common practice. Then you shouldn't need the build ID. Tools that need to verify images should also check attestation files or additional metadata.

That would look like 20240515111413-git1da9c71

This aligns it with the packaging tags using 1.21-gitdfe7b0f
https://github.com/GeoNet/haz-sc3-producer/releases/tag/1.21-gitdfe7b0f

[wilsonjord]

Then you shouldn't need the build ID. Tools that need to verify images should also check attestation files or additional metadata.

The build id was to allow, for a given image, what version of docker-gamit was used (via the commit sha), and what version of docker-gamit-base was used (via examination of the build associated with the build id). I'll need to understand how attestation / additional metadata would solve this particular issue.

Anyway, I'm happy to drop build id from the default tag, if it's not useful, as the end user can add build id themselves to their tagging scheme if they really needed it.

An alternative would be to have build id as an option behind some sort of include_build_id type flag.

That would look like 20240515111413-git1da9c71

That looks good, I'll make the change, thanks.

[CallumNZ]

what scenarios does the || github.sha account for?

[wilsonjord]

Most commonly, it accounts for push to main, which typically happens on PR merge; github.sha will be the last commit of main.

[CallumNZ]

⭐