Split version updates into two steps to fix antora docs generation

[ryanjbaxter]

Main changes are in

BumpBackToSnapshotsProjectOnlyReleaseTask.java PushSnapshotChangesForProjectOnlyReleaseTask.java

These two tasks are very similar to existing tasks BumpBackToSnapshotReleaseTask.java PushChangesReleaseTask.java

In fact PushSnapshotChangesForProjectOnlyReleaseTask does the exact same thing as PushChangesReleaseTask but in a different order. BumpBackToSnapshotsProjectOnlyReleaseTask uses the same method as BumpBackToSnapshotReleaseTask. but removes all all projects (aka dependencies) except for the project we are releasing. After we bump the version of the project we are releasing only we push those changes using PushSnapshotChangesForProjectOnlyReleaseTask. Then we run the task to build our docs at that point we have a tag for the release in GitHub and on main the version for the project is using the next snapshot release version but all the Spring Cloud dependencies have not yet been updated. Antora will run, clone main and build the snapshot docs for the next release and it will also build the tag for the release. This avoids the error where Antora will complain that we are building docs for a tag that already exists (ie our snapshot version on main is the same version as one of tags).

After the docs build runs we run (the existing tasks) BumpBackToSnapshotReleaseTask to bump all the dependency snapshots and then run PushChangesReleaseTask which pushes those changes to GitHub.

The test that verifies this is here https://github.com/spring-cloud/spring-cloud-release-tools/pull/316/files#diff-ef7e2a1115da456da86188e6b3b183246d3de8f86468337a5600371c457478d9R173

[spencergibb]

Big commit can you point out a few places that are the most interesting to review? Where the split is and where it is tested?

[ryanjbaxter]

@spencergibb i was in the middle of updating the description when you wrote that, it should be more clear now