bt2: generate native extension as C++

bt2: generate native extension as C++

Make SWIG generate the native code in C++ rather than C.  The
differences in the generated file (`native_bt.cpp`, previously
`native_bt.c`) are not significant (use of C++-style casts instead of
C-style casts, use of new/delete instead malloc/free, etc), but it will
allow us to use C++ in the typemap code.  It will help to integrate
better with other utils that are or will be written in C++.

Unfortunately, this requires more distutils hackery.  It looks like
distutils (both the copies distributed with CPython < 3.12 and the copy
in setuptools < 72.2.0) doesn't have good support for building objects
from C++ files that will end up in shared objects.  The `compiler_so`
executable gets used, defined here [1] as using the C compiler.  If
using a recent enough compiler that defaults to C++11, it works (when
calling `gcc` or `clang`, rather than `g++` or `clang++` they understand
that you want to compile C++ based on the file suffix).  But on an older
system (e.g. SLES12) with gcc 4.8, we get errors like:

    In file included from bt2/native_bt.cpp:3296:0:
    /babeltrace/src/bindings/python/bt2/bt2/native_bt_autodisc.i.h: In function 'bt_value* bt_bt2_auto_discover_source_components(const bt_value*, const bt_plugin_set*)':
    /babeltrace/src/bindings/python/bt2/bt2/native_bt_autodisc.i.h:118:9: warning: 'auto' changes meaning in C++11; please remove it [-Wc++0x-compat]
       const auto autodisc_result = static_cast<auto_source_discovery_result*>(
             ^

Things appear to have improved in setuptools 72.2.0 [2], where there's
now a `compiler_so_cxx` executable that uses the C++ compiler.  This
release doesn't appear widely available in Linux distros right now (for
instance Arch is still at 69.5.1), and we need to support distutils all
the way back to Python 3.4 anyway.

The new distutils hackery is inspired by this blog post [3].  The idea
is to override the `build_extensions()` method of
`distutils.command.build_ext.build_ext` method to set the executables on
the `distutils.ccompiler.CCompiler` instance.  Because this way of doing
things overrides the flags previously determined by distutils, we can
handle here the other hacks:

 - the hack to force our CFLAGS over sysconfig's CFLAGS (which now
   becomes CXXFLAGS because C++)
 - the hack to manually convert the include paths form on MinGW

I add to the `compiler_so_cxx` command the result of
`sysconfig.get_config_var("CCSHARED")`, which is analogous to what is
done in [2].  On Linux, for instance, this contains `-fPIC`, which is
necessary to produce objects files intended to be used in shared
objects.

[1] https://github.com/pypa/setuptools/blob/v72.1.0/setuptools/_distutils/sysconfig.py#L355-L357
[2] https://github.com/pypa/setuptools/blob/v72.2.0/setuptools/_distutils/sysconfig.py#L360-L363
[3] https://shwina.github.io/custom-compiler-linker-extensions/

Change-Id: I5999292d3a14948ef5f675a924e2360bc4d73f13
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/13431