See merge request nexedi/slapos!1453

  There are extra libraries and patches that are important to wendelin (bt5) usage,
  DataArray, DataSupply...

now we have a test extra

Some configure scripts, such as cmake's FindPython3, use explicit
python version such as python3.9 and can find system python, although
using python3 would be catched by the disabled python. With this change
we also catch attempt of using python3.9

We also print the executed command, it helps guessing what executed
python

configure is a python script that autodetects the python interpreter
and may use a system python, execute the script with software release's
python directly.

there was a typo environement/environment, so slapos python was not
used. Another problem is that open62541 vendors (see [1]) an old version of
cmake's FindPython3 which does not lookup versions more recent that 3.8.

Fix this by removing the vendored FindPython3 to use the one from cmake.

[1]: https://github.com/open62541/open62541/blob/v1.3/tools/cmake/FindPython/Support.cmake#L20C7-L20C34

On debian 11.2 with zlib1g-dev installed this uses system zlib

After the changes in 565f4986, Flask need recent version of MarkupSafe
so we must align the version of MarkupSafe and Flask.

1c4a3c69 (stack/slapos.cfg: version up eggs (requests 2.31.0 and
friends), 2023-10-04) broke component/nxdtest/test-py2.cfg and
others using pytest on python2

This part of 30804165 (component/apache-php: add missing xz in PATH,
2023-10-17) was pushed accidentally

This is required for xz archives

See merge request nexedi/slapos!1450

This is required because it depends on an older version of Jinja and
updating in 565f4986 (stack/slapos: version up Flask and friends
(itsdangerous, Jinja2, MarkupSafe, Werkzeug), 2023-10-12) broke jupyter
software

At the same time, move some pins from stack/erp5 to stack/slapos as they
become used by more softwares

previous patch - 24f5a96c (software/slapos-sr-testing: disallow usage
of system python3, 2023-10-02) - was incorrect, an `entry-point` is
required for a script to be generated.

We can not rely on system python here, it's a bit better to rely on
buildout's python ( the main reason is that it complies with
slapos-sr-testing not having system python ).

The implementation is a bit complicated, we can not just reference
${buildout:executable} in the profile, because doing so will cause an
infinite loop with rebootstrap and software installation never finish
because options of ca-certificates change at every run if they include
the python path. Instead, we use a pre-make-hook to rewrite the Makefile
without saving the interpreter in option. This python is only used
during the build process (to generate the certificate files) and not
used at run time, so it does not really depend on python strictly
speaking. Anyway, because it's a component used very early in the
bootstrap, we can not reference python here.

This software autodetects python2 and python3, so provide both