[CI] add check for packages needing version increment

[infotroph]

Description

• New script ensure_version_bump.sh takes a Git tag (defaulting to most recent) and a path (defaulting to cwd) and complains about any R package under that path that both (1) has any changes since the tag; and (2) has not changed its package version.
• Added ensure_version_bump to the CI/check GHA workflow
• Bumped versions of the packages that needed it

Motivation and Context

Way back when, all PEcAn packages shared a version and we incremented it each time we tagged a PEcAn release.

Then we started versioning each package individually, but with a mass version bump both before (setting intended release version following semver rules) and after (appending '.9000' to each package to indicate an unreleased development version) tagging each release. This meant it was not possible for a package to keep the same version across two PEcAn releases, even if nothing had changed in the package. It also meant there was no clear way to release the same version of a package both inside and outside of a PEcAn system release (e.g. if we started submitting packages to CRAN).

Starting with PEcAn 1.9.0, we decided to stop mass-adding the .9000 suffix and instead expect a version bump in the first PR that touches each package after release. Then if we are not updating a package there is nothing further to do to it at release time, extraneous version increments are eliminated, and each package can be set to its next release version whenever we finish work on it; no need to wait for a release branch.

The obvious drawback of expecting version bumps to be done during routine PRs rather than at release time is that it's easy to forget to do them -- see as evidence the 18 packages I'm updating after the fact here! Hence this PR to make the robots remember for us.

Review Time Estimate

• Immediately
• Within one week
• When possible

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• My name is in the list of CITATION.cff
• I agree that PEcAn Project may distribute my contribution under any or all of
  • the same license as the existing code,
  • and/or the BSD 3-clause license.
• I have updated the CHANGELOG.md.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.