…oyment branches

* Pull up branch detection and plugin config extraction from the MasterPromotExtension to AbstractBranchDetectingExtension.
* Introduce OtherBranchVersionExtension, responsible for updating project versions based on the 'otherBranchDeploymentPattern'.
    * Updates project versions of MavenProjects in the reactor.
    * Parent references in the reactor model are by reference, so we don't have to update 'parent' relations on projects.
    * Iterates all reactor projects to update any (managed)dependencies or (managed)plugins.
* Removed artifact version manipulation from the RetargetDeployMojo -- which no longer needs to do that.
* Introduced basic multi-module IT stub.
    * Parent pom
    * Child modules with a dependency (Child2 -> depends upon -> Child1)

Notes:

* Still missing automated ITs on this - I was making this a 'poc' to see if it was feasible before I started writing exhaustive test cases.
* mvn initialize will fail for update-stage-dependencies on child2, however mvn package will succeed.
    * The lack of a resolvable dependency in the reactor, or in the remote stage repo keeps update-stage-dependencies from succeeding.
    * When the jar is built as part of the reactor, it finds the dep in the current reactor just fine. This is... wonky.
* I have not checked the output pom.xml's in the target to determine if their versions are being written based on the updates from the extension.

* Adjusts the artifact versions for the default project artifact.
    * Other artifacts attached by the build use these versions as the basis.

* Massage both effective in-memory models and original model (unalterd POM) of the project.
* Update project state (and hierarchy of projects) whereever possible.
* Retarget Deploy is really simple now. :-)
* Updates the OtherBranchVersionExtension to handle project massaging and emission of the massaged pom.
* The normal ProjectDeployer from maven-artifact-transfer works quite will with this POM swapping.

…erBranchVersionExtension

…ies from the main session to the nested maven execution

… well.

…e other branch suffix being applied to a version repeatedly (+normalized-branch-name+normalized-branch-name-SNAPSHOT)

…om:rdefreitas/gitflow-helper-maven-plugin into feature/partial-multi-module-reversioning

Bumps [junit](https://github.com/junit-team/junit4) from 4.8.2 to 4.13.1.
- [Release notes](https://github.com/junit-team/junit4/releases)
- [Changelog](https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.1.md)
- [Commits](junit-team/junit4@r4.8.2...r4.13.1)

Signed-off-by: dependabot[bot] <support@github.com>

… execution. This is due to that additional execution clearing a ThreadLocal reference to the Session, that subsequent plugins/code may depend on (ie IntelliJ's Maven integration).

…e nested Maven execution. Changed from creating one from scratch, towards basing it on the request from the session, copying it, removing unneeded aspect and changing others.

…anch-renaming

Prevent repeated OtherBranch name suffixes being appended

…-reversioning

Extended the OtherBranchVersionExtension to deal with partial multi-module builds

…nit-4.13.1

Bump junit from 4.8.2 to 4.13.1