Consider reformatting the ROPP version number

[Ian Culverwell]

ROPP-10 beta reviewers Christian Marquardt and Leonid Butenko say:

The version of the ROPP libraries and tools is available through the
ropp_xx_version() functions, where a version string is hardcoded (usually in
common/ropp_xx_version.f90). In at least one place
(ropp_io/ropp/bgrasc2ropp.f90, line 452) this version string is parsed to
extract a numerical representation. 

However, this parsing relies on the version number starting at the second
position in the string and being followed by a blank (\u2019 \u2018) character.
This excludes versions with patch levels or other modifications (e.g., v10.0.1,
v11.0-beta), and thus violates the now common approach to semantic versioning. 
The problem is that programs using bggrasc2ropp will crash without giving an
error message

We found no documentation that the version string must follow the above
convention, and prohibits use of the common semantic versioning rules. The
source code should at the very minimum contain a comment above the definition of
the version string that this convention must be followed. A better solution
would be to have the parsing of the version string allow a wider range of
version formats; note that for semantic versioning, appropriate regular
expressions are known (see https://semver.org/).

Note: We fixed this in our ROPP v10 version in #7f6433a4 by modifying our
version string; better parsing would be preferred.

We also wondered why the version information provided in configure.ac (in the
AC_INIT() call) isn\u2019t used to update the version strings during
configuration; it would simplify version updates considerably.

Consider, at a low priority, for ROPP-11.0.

[Ian Culverwell]

To be done "whenever" (we have the same resources as EUM or DMI to do this sort of thing).