Convert nightly build to a versioned build

[spbolton]

Instead of the nightly build just building the latest master commit and pushing it with a git tag "nightly" but still using the 1.0.0-SNAPSHOT version we should make use of the versioned builds structure that will help to exercise this behavior as the code promotes up to a full release branch. The nightly build is a first step in the promotion of the code ensuring higher confidence in quality until the commit makes it into a release. The key to the promotion process is that we are not modifying any code, but are only storing the version metadata in the .mvn/maven.config file. This has been enabled since we have used ci friendly versions in maven https://maven.apache.org/maven-ci-friendly.html. We have already exercised this behavior in the cli-release-process.yml. although we will be spliting out the promotion step from the rest of the workflow as well as looking to combine this cli-release-process with an overall release process for the whole product in the other steps in this epic.

The only real difference with the nightly build is that rather than promotion being a manual step, it is instead automatic based upon the nightly schedule. The version is also automated based upon the current date. In github the "nightly" tag is always updated with the latest successful build but we also will deploy with full verison eg. "nightly-20240805".
In the nightly-promote.yml we will set the maven version and push it to a "nightly" branch which we will control with branch protections to ensure it can only be pushed from master.

The commit of the version in the .mvn/maven.config will have a few impacts.

1. It will force a new commit id. This will prevent test failures and workflow errors from getting pulled together with those from main build and merge queue.
2. The existing build/test will use this revision by default.
3. It will chain of history as a particular commit is promoted. To do this we should add the original master commit id into the ./mvn/maven.config that can be reported in the build and version information of the product to always know which master commit any build and release is based upon.

After this step is done, we can then extend this into manual promotion to release candidate / release branches, in these case it is a deployment approval that allows the promotion to the subsequent stage.