Perform ABI bumps when they happen, not at release time

[gilles-peskine-arm]

At the moment, if there's an ABI change in one of the libraries, we perform a version bump at release time.

This is an annoying step in the release process. We've been known to forget, or to make a mistake when checking (the tool we use is brittle, for example the version we use on the CI silently fails on modern systems).

I think we should change our process to increment the ABI version as soon as it deviates from the last release. Then we might still want to double-check at release time, but normally we'd be covered. This means:

• CI must compare the ABI with the previous release, only for the libraries whose soversion hasn't changed. E.g. if the last release has {crypto=42, x509=2, tls=7} and the branch being tested has {crypto=43, x509=2, tls=7}, then the CI compares the ABI of x509 and tls but not crypto. The CI always compares the API with the previous release.
• We need to have clear instructions on how to do an ABI version bump (not scripts/bump_version.sh which wants a new API version — it's easiest to edit library/Makefile and CMakeLists.txt manually).
• As things stand, if two pull requests want to bump the ABI of the same library concurrently, that's ok: they'll make the same changes to the same lines in library/Makefile and CMakeLists.txt. But if one PR bumps e.g. crypto and another one bumps x509, there'll be a merge conflict because of consecutive edited lines. To avoid that we'd need e.g. a blank line between each SOVERSION number.
• Since we'll be doing SO version bumps more often and more manually, we may want to have a single source of truth for the SO versions. If not we should check coherence in the CI.

Possible prerequisites:

• abi_check.py reports no changes on Ubuntu 20.04, Ubuntu 22.04 or macOS mbedtls#5332
• Improve GitHub reporting of ABI-check #48
• Race condition in target branch selection in the ABI-API-checking job #37 (or maybe that one would become moot, since we'd be selecting the commit to compare with differently?)

[tom-cosgrove-arm]

But if one PR bumps e.g. crypto and another one bumps x509, there'll be a merge conflict because of consecutive edited lines

Will this happen frequently enough for it to be a problem?

[gilles-peskine-arm]

But if one PR bumps e.g. crypto and another one bumps x509, there'll be a merge conflict because of consecutive edited lines

Will this happen frequently enough for it to be a problem?

Maybe not. But I think it's easy to avoid, just by adding a comment and a blank line above each version number in library/Makefile (they're already separated in CMakeLists.txt).