Prune all Python versions from hosted tool cache prior to building

[philippjh]

In #256 we were seeing the following build failure:

CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Python3 (missing: Interpreter) (Required is at least version
  "3.6")

      Reason given by package: 
          Interpreter: Cannot run the interpreter "/__t/Python/3.11.11/x64/bin/python3"

It turned out, that the problem is coming from Python requiring a newer GLIBC version inside the container.

/__t/Python/3.11.11/x64/bin/python3: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /__t/Python/3.11.11/x64/lib/libpython3.11.so.1.0)

However, spawning the container locally and downloading the used Python 3.11.11 from GitHub's own Python release list, I wasn't able to reproduce this problem. It turned out, that the hosted tool cache, for some reasons, holds a distribution which is linked against the newer GLIBC and the setup-python action would not recognize that and (re-)fetch the Python package.

This PR effectively disables the caching by pruning all previously fetched Python versions from the hosted tool cache.

[julio-gorge]

This is quite the nuclear 💣option, have we tried passing a specific Python 3.11 version to setup-python@v4 to force it to upgrade existing Python 3.11 installation to a certain 3.11.<patch> version, or using check-latest: true?

check-latest:
    description: "Set this option if you want the action to check for the latest available version that satisfies the version spec."
    default: false

uses: actions/setup-python@v4
        with:
          python-version: ${{ inputs.python_version }}
          check-latest: true

[philippjh]

I agree. However, explicitly setting the requested Python version to 3.11.11 did not work, I was still seeing the glibc error from the distribution present in the tool cache. I'm not sure about check-latest, though. I reckon, that this switch is only functional, if you loosely specify the requested Python version, e.g., 3.11 instead of 3.11.11. In this case the routine resolves to the latest release, that still satisfies the version specifier (e.g., 3.11 -> 3.11.11). The code of the action also supports this claim, imo.

[philippjh]

As the issue was popping up in another PR, I had the opportunity to confirm, that both setting check-latest to true and enforcing the requested Python version to be 3.11.11 is not sufficient to resolve this issue. I advocate to proceed with the changes proposed in the PR to unblock developers.

[philippjh]

Upgrading setup-python to latest v5 also does not fix the issue.

[julio-gorge]

Good to get devs unblocked. Would be nice to address this another way in the future.

[andcarminati]

LGTM.

[philippjh]

We're proceeding with #275, which contains the upstream fix for the issue this PR is solving.