Consider simplifying API version maintenance for BIND libraries

Currently, for every single BIND release, we consider how the library API version files (lib/*/api) need to be updated in order to prevent runtime issues when multiple versions of the same library end up being present on a given host. While such issues are pretty much bound to be a result of either a developer hacking on BIND or a user having a mess on a host - and despite the fact that in BIND 9.16+ the shared libraries shipped with BIND are considered internal to BIND - we keep on spending non-negligible amounts of time debating how exactly to proceed in various different ABI change cases (with the help of the results of the abi-check GitLab CI job).

In other words, we seem to be repeatedly spending time on debating something that is very unlikely to cause trouble for most users and could be automated (e.g. by automatically bumping SOVERSION for every library on every release).

There are a few ways to change the paradigm. Arguably the simplest one is to "hardcode" the BIND version number into the version number of each shared library shipped with BIND. This way a binary coming from a given BIND release would only be able to run against the shared libraries coming from the same BIND release, while it would still be possible to have multiple versions of these libraries available on the same host, if necessary.

The extent of these changes in terms of the branches it would influence is up for discussion as well. It seems to me that limiting this change to BIND 9.16+ would be a reasonable compromise.