Fix format of version string

[Ian Culverwell]

ROPP-10.0 beta reviewers 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. This parsing relies on the version number
starting at the second position in the string and being followed by a blank ('
') character. Note that 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 potential problem is that for users
modifying the version string (e.g. in order to indicate that they have rolled
out an adapted version of the software) some programs will crash without giving
a meaningful error message; this is actually how we became aware of the problem.

We found no documentation that the version string must follow the above
convention, and prohibits use of the common semantic versioning rules. In our
view, the source code should contain a comment close to the definition of the
version string explaining this convention. A better solution would be to have
the parsing of the version string allowing 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
https://gitlab.eumetsat.int/ro/ropp/commit/7f6433a46f525e4adfe85e68949be35a3452b995
by modifying our version string; however, better parsing would be preferred. We
further wondered why the version information provided in configure.ac (in the
AC_INIT() call) isn't used to update the version strings during configuration;
after all, this is why automake requires a version string in this call. Using
this feature of the build system would simplify version updates considerably.

I note that the reviewers chose to spend time on this rather than reviewing the 2D wave optics propagator, for example.

[Ian Culverwell]

Don't know why this is a ROPP9.1 carry over ticket. Moving to ROPP-11.0.

[Ian Culverwell]

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