Fix bump-pom-scijava.sh to update versions "in advance"

[dscho]

Moved from scijava/scijava-common#22.

The current bump-pom-scijava.sh has some limitations which we should address before pushing artifacts to Maven Central en masse.

The following scenario recently occurred:

• pom-scijava 1.100 has imglib2.version of 2.0.0-beta-20 and imagej.version of 2.0.0-beta-7.5.
• pom-scijava 1.101 bumped imglib2.version to 2.0.0-beta-21, an incompatible change since subsequent betas do not follow SemVer yet.
• pom-scijava 1.105 further bumped imglib2.version to 2.0.0-beta-22, another incompatible change.
• In particular, although we try to deprecate old functionality in a release before removing it in a subsequent release, the fact remains that between ImgLib2 versions 2.0.0-beta-20 and 2.0.0-beta-22, there are definitely API incompatibilities such as the CompositeXYProjector class migrating to a new package.
• However, ImageJ version 2.0.0-beta-7.5 continues to depend on ImgLib2 2.0.0-beta-20. So consequently, pom-scijava 1.105 and above recommend incompatible library versions of ImgLib2 and ImageJ2, respectively.

Really, when a library is bumped to an incompatible (i.e., major) new version, all downstream projects of that library also need to be updated and released and bumped inside pom-scijava as well, or else the version recommendations clash.

A solution that @dscho proposed is to bump versions "preemptively"—i.e., before they have actually been cut. Then the release itself can have the new pom-scijava version as its parent, and the version properties of the release itself will be consistent.

However, ultimately, whenever a new major version of an upstream library is released, we still need to do the work of cutting a release of each downstream library as well (probably all with new major version numbers).

We should get ImgLib2 and SCIFIO out of beta as soon as possible, and start respecting SemVer conventions and avoiding major version bumps, to avoid these problems whenever possible. But when major releases are deemed necessary, it would be good to be clear on how bump-pom-scijava.sh should behave in those cases.

[ctrueden]

The bump-versions-in-pom.sh script was retired earlier this year, along with the Bump-POM-SciJava Jenkins job. See also #3.