Set libhackrf version to 0.9.1

[martinling]

This is a change to make our build system more consistent with previous behaviour, and with Semantic Versioning.

In the past, we specified only a MAJOR.MINOR version for libhackrf in CMake, and also reported that format in the string returned by hackrf_library_version(), e.g. 0.9.

However, when installing the .so shared library, we always appended an additonal .0 to the version, in order to give a filename such as libhackrf.so.0.9.0; effectively a MAJOR.MINOR.PATCH version with the PATCH component hardcoded to zero.

PR #1578 / #1586 simplified the version handling in our CMake files, and in the process, accidentally broke the .so file versioning completely. PR #1589 fixes that, but now installs a filename of libhackrf.so.0.9, without a PATCH component.

In general, we have a policy at GSG to follow Semantic Versioning. Doing so would dictate that we include a PATCH component, and that we increment this when we make backwards-compatible fixes that don't add new API.

Since shipping libhackrf 0.9 in our 2024.02.1 release package, we have made one backwards-compatible change to the library: the addition of RAW_IO support in PR #1483.

Therefore, let's now set the library version to 0.9.1.

Since the installation now uses the CMake PROJECT_VERSION variable, this change restores the previous installation behaviour i.e. install an .so file with a MAJOR.MINOR.PATCH filename.

It also changes the string reported by hackrf_library_version(), and therefore also by hackrf_info, from 0.9 to 0.9.1.

The latter is a user-visible change in behaviour, but one that is consistent with both Semantic Versioning, and with the libhackrf API documentation: which specifies only that the result of that call will be a human-readable string identifying the library version.

[mossmann]

Excellent, thank you!