Fix docker image labels

[jhkennedy]

Before this PR our images labels after a release typically looked like:

which is less than desirable (see #278 for details). After this PR, image labels instead should look like:

This has been facilitated by switching to a version-number-centric workflow instead of branch-centric workflow and taking advantage of GitHub's workflow concurrency groups.

Notably:

• the version_tag passed to the dockerize workflows must conform to PEP 440
• images will still be tagged with the version_tag, but the workflow will only allow one concurrent execution per unique version_tag
• test tags will be applied to pushes of developmental versions
• latest tags will be applied to pushes of all non-developmental versions (releases).

The main departure from the expectation (not reality) of our previous workflows is that, for normal releases from the HEAD of the development branch, the test tag will get "left behind" on that HEAD commit when the develop->main merge commit is fast-forwarded back to develop, so you won't see an images tagged vX.Y.Z, latest, and test at the same time. This, I think, is fine, and facilitates hotfix releases (e.g., workflow won't pull test back from develop to the new tag)

You can see my testing of it from a feature branch -> develop -> main -> release in ASFHyP3/hyp3-test-cookiecutter, starting with ASFHyP3/hyp3-test-cookiecutter#6 and the subsequent release PR ASFHyP3/hyp3-test-cookiecutter#5.

Important

These proposed changes allow for bumpless "releases" (really, it's only a merge to main) as long as we don't trigger on pushes to main (or really, any not-develop branch)! (This means a bumpless merge to main won't have a container built for it.) Otherwise, the version number computed for the bumpless merge commit on main will be a development version number and pull the 'test' tag to the main branch.

While not required, I think we should consider disallowing bumpless merges and/or switch to post-releases for that use case. Main really only serves to facilitate release PRs, which require a release branch, and I cannot think of a reason to have commits on main that aren't release merge commits (I went back through our bumpless releases and don't see any significant utility to them).

Post-releases would also solve the problems I got hung up on here: #234

---

This PR also:

• removes the reusable-git-object-name.yml workflow as it does not produce PEP 440 compliant version numbers and is currently only used within the update-examples.yml workflow in this repo across all of GitHub.
• updates the updates-examples.yml workflow to not depend on reusable-git-object-name.yaml

---

Fixes #278

[jtherrmann]

Additional testing screenshots in this thread: https://chat.asf.alaska.edu/asf/pl/kykwargec7y1dcn1r96hiryojy