build: allow for possible v1 branch continuity by generous SONAME offset

The main and the most ABI-touching thing for the envisioned 2.0 branch
is the usage of the linker-build-time allocated callsite info, avoiding
the non-economic evaluations and, under some circumstances dangerous,
heap allocations in the run-time.

Considering that v1.9.0 release (libqb.so.20) was expressly marked as
tech-preview[1,2] (hence something that shall not make it to production
use), there should be no harm for master branch (that is headed towards
2.0 and beyond) to receive noticable SONAME bump (libqb.so.100) so as to

• leave enough of space for a possible v1-compatible branch evolution (for use cases where recompile-everything is a no-go). in particular, with resuming with libqb.so.30, there would be a room for 99-33 = 63 add-new-drop-nothing compatible changes for that branch (which is more than plentiful)

• indicate some big change is going on more clearly towards client space

This is supposed to be a reasonable trade-off solution that would still
leave enough wiggle space, and would represent responsible approach to the
development (like the original attempt to prevent ABI break in the first
place was), allowing for more than an enforced unanimity (rather
antagonistic in the free software realms).

[1] https://lists.clusterlabs.org/pipermail/users/2019-December/026690.html
[2] https://github.com/ClusterLabs/libqb/releases/tag/1.9.0

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>