component/glib: put slapos python3 in PATH

On old debian (9) where python3 is python3.5 this component fails to
build with an error like:

    Configuring gdbus-example-objectmanager-visibility.h with command
    Running command: /opt/slapgrid/shared/glib/60e920f1feec2451d51bb344cfcad9ab/.build/glib-2.76.3/tools/gen-visibility-macros.py 2.0 visibility-macros GDBUS_OBJECT_MANAGER_EXAMPLE /opt/slapgrid/shared/glib/60e920f1feec2451d51bb344cfcad9ab/.build/glib-2.76.3/builddir/gio/tests/gdbus-object-manager-example/gdbus-example-objectmanager-visibility.h
    --- stdout ---
    --- stderr ---
      File "/opt/slapgrid/shared/glib/60e920f1feec2451d51bb344cfcad9ab/.build/glib-2.76.3/tools/gen-visibility-macros.py", line 37
        """
        ^
    SyntaxError: invalid syntax

This is because this gen-visibility-macros.py script is executable with
a shebang:

    #!/bin/env python3

for python 3 softwares, this is slapos python, because the python
section from component/defaults.cfg injects the slapos' python in PATH,
but for python 2 software, slapos' python 2 is injected in path and
`python3` resolves to system python, which in that case fails because
f-strings are SyntaxError but more generally this showed a dependency
to system python, but we can not rely on system python here.

component/glib/buildout.cfg

@@ -7,6 +7,7 @@ extends =
   ../patch/buildout.cfg
   ../pcre2/buildout.cfg
   ../perl/buildout.cfg
+  ../python3/buildout.cfg
   ../pkgconfig/buildout.cfg
   ../xz-utils/buildout.cfg
   ../zlib/buildout.cfg
@@ -27,7 +28,7 @@ make-binary = ninja -C builddir
 pkg_config_depends = ${pcre2:location}/lib/pkgconfig:${libffi:location}/lib/pkgconfig:${zlib:location}/lib/pkgconfig
 environment =
   PKG_CONFIG_PATH=${:pkg_config_depends}
-  PATH=${ninja:location}/bin:${pkgconfig:location}/bin:${patch:location}/bin:${perl:location}/bin:${xz-utils:location}/bin:%(PATH)s
+  PATH=${python3:location}/bin:${ninja:location}/bin:${pkgconfig:location}/bin:${patch:location}/bin:${perl:location}/bin:${xz-utils:location}/bin:%(PATH)s
   CFLAGS=-I${gettext:location}/include
   LDFLAGS=-L${gettext:location}/lib -lintl -Wl,-rpath=${gettext:location}/lib -Wl,-rpath=${libffi:location}/lib -Wl,-rpath=${zlib:location}/lib -Wl,-rpath=@@LOCATION@@/lib -Wl,-rpath=${pcre2:location}/lib
 post-install = rm %(location)s/bin/gtester-report

[Julien Muchembled]

Ideally, what we'd like to use is ${meson:python}.

[Julien Muchembled]

My mistake, we could imagine that meson works with Python 3.5 and I guess that gen-visibility-macros.py has no direct relation with meson.

I always have in mind to not force things unnecessarily to the user. And one way to reduce the size of SR build would be to not build components that aren't used by the instance, when versions rarely matter. Because well, frankly, who cares about the version of autotools, perl when configuring openssl, go to build go. [gcc] was a first step in this direction and the same range mechanism could be applied to [python]. I have other ideas but that's probably no the best place to discuss that.