Create reusable-promote.yml to promote and tag changes from source branch to destination

[spbolton]

When running a release instead of all steps being run in a single workflow run including generating a release branch and persisting the release version in the commit it is better to split this into two steps.

1. A manual action to accept the promotion of code that has made it successfully into another protected branch e.g. master and move it to a destination branch while also setting the revision to build against within that commit.
2. An automated workflow that runs on a "push" event to the destination branch to build the code, run tests, deploy, release tasks, then report and notify.

This task is the first step here and is equivalent to the steps in maven-release-process.yml upto and including the Set Release Version step. There are some changes to this process to clean up we need to consider.

1. Rather than creating a temporary branch for each release version we should push to the head of a common "release" branch and tag the release commit.

Create this as a reusable workflow so it could be used for other promotions we may add e.g. master -> QA -> release

Create promote_release.yml workflow to call the reusable-promote.yml specific to promoting from Master to Release

Questions:

1. should we set a version into .mvn/maven.config. of interim commits that make up the release, we will only use these commits for change list history and possible diagnosing introduction of issues.
2. Do we allow for the recreation of a release by adding more commits, do we change history in this case? ....

[spbolton]

The cli release process has been integrated already in the main workflows, but does not separate the promote and build/release steps. see cli-release-process.yml