Release procedure should handle older patch releases gracefully

[devinrsmith]

This is mainly about our release procedure always labeling the active release as "latest".

#5591
#5572
deephaven/deephaven-server-docker#94

We should come up with a consistent way to determine whether the active CI release process is the newest "latest" release or not. Potential solutions may involve looking at the current release version wrt the git tags. There may be other metadata we can attach to our git repo; a "latest" tag is not really appropriate (tags are supposed to be immutable), but we could consider a "latest" branch that is always set to the latest release (at which point, we can get the canonical release version associated with that commit); or potentially some other mutable git data.

We could also consider using the Github release API as the canonical source, and use that to figure out what the latest release is: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#get-the-latest-release

We could also consider using workflow_dispatch as a means to start the release procedure (as opposed to pushing to a release/v* branch); in this way, the release manager could set a flag as to whether the current release will become the new "latest" release or not. Structurally, this might be the "best" as it provides a more structured approach to releases. This could be combined with a safety check (one of the earlier suggestions) to double check and make sure both automated procedures and the release manager agree whether this release is "latest" or not.

[mofojed]

We cannot use a dist-tag of v0.33 for example, otherwise we get an error when publishing:

Run npm publish --tag v0.33 web/client-api/types/build/deephaven-jsapi-types-*.tgz
npm ERR! Tag name must not be a valid SemVer range: v0.33
npm ERR! A complete log of this run can be found in: /home/runner/.npm/_logs/2024-07-22T13_50_46_671Z-debug-0.log

This is detailed in the docs: https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#caveats

The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter v.
I am a little confused how web-client-ui packages have been publishing with these dist-tags, as @deephaven/code-studio for example has many tags with "semver" version numbers: https://www.npmjs.com/package/@deephaven/code-studio?activeTab=versions
https://github.com/deephaven/web-client-ui/blob/882980d329080a850be0515290344afe8545d5a8/lerna.json#L6

But we can avoid this by adding a release- prefix before the version number, then it should be a valid dist-tag and not conflict with semver.