[Python] add compatibility testing

The Kudu Python client declares support for Python 2.7 and 3.6–3.11
in its trove classifiers, but had no mechanism to verify that the build,
test suite, and sdist packaging actually work across all those versions.

build-support/python-compat/ fills this gap with shell scripts that
bootstrap each interpreter via the deadsnakes PPA and exercise the
full build+test+package cycle per version:
  bootstrap-deadsnakes-python.sh  install all supported interpreters
  test-client.sh                  build extension + run test suite
  test-packaging.sh               sdist round-trip in a clean venv

test-client.sh supports a -j [N] flag for parallel execution across
versions (mirroring make -j semantics).  Parallel builds are safe
because each version gets its own isolated copy of the source tree
under /tmp: setup.py generates several files in-tree at import time
(config.pxi, version.py, kudu/*.cpp) that would otherwise race when
multiple interpreters build concurrently.  The source tree is cleaned
once up-front and then copied per version with cp -aL (dereferencing
symlinks such as version.txt -> ../version.txt) so every build starts
from a known-clean state.

Tools like tox exist for exactly this kind of test-matrix work, but
supporting a range that stretches back to Python 2.7 requires older
virtualenv versions that conflict with modern toolchains, making a
tox setup more brittle than the straightforward shell scripts here.

These scripts are intended to be run manually by developers when
adding or dropping a supported Python version, and as part of the
release checklist to confirm packaging works across the full matrix.
They are not wired into CI.

DONT_BUILD

Change-Id: Id1f4e6c837a0a3e9da531627ec38f1c452341c11
Reviewed-on: http://gerrit.cloudera.org:8080/24155
Reviewed-by: Zoltan Chovan <zchovan@cloudera.com>
Tested-by: Marton Greber <greber.mx@gmail.com>
Reviewed-by: Zoltan Martonka <zmartonka@cloudera.com>