Use Python 3.10 in CI instead of Python 3.9

[Luthaf]

Description

Use Python 3.10 in CI instead of Python 3.9 which is EOL (see https://github.com/plumed/plumed2/pull/1348#issuecomment-3542694561)

There are also references to Python 3.9 in the following places, I can also update them if you want:

• plugins/pycv/pyproject.toml sets requires-python = ">=3.9"
• docker/rocky8 is installing Python 3.9.16
• conda/py-plumed/conda_build_config.yaml is building for 3.8, 3.9, 3.10

There are also multiple bash script doing something like

for python_bin in python python3 python3.12 python3.11 python3.10 python3.9 python3.8 python3.7; do
    if $python_bin -c "import plumed" 2>/dev/null; then
        if [ $python_bin != python ]; then
            PYTHON=$python_bin
        fi
        return 1
    fi
done

But I think these can stay as-is.

Target release

I would like my code to appear in release v2.10

Type of contribution

• [x] changes to code or doc authored by PLUMED developers, or additions of code in the core or within the default modules
• [ ] changes to a module not authored by you
• [ ] new module contribution or edit of a module authored by you

Copyright

• [x] I agree to transfer the copyright of the code I have written to the PLUMED developers or to the author of the code I am modifying.

• [ ] the module I added or modified contains a COPYRIGHT file with the correct license information. Code should be released under an open source license. I also used the command cd src && ./header.sh mymodulename in order to make sure the headers of the module are correct.

Tests

• [x] I added a new regtest or modified an existing regtest to validate my changes.
• [x] I verified that all regtests are passed successfully on GitHub Actions.

[Luthaf]

CI failure is a segmentation fault in the Python tests, so it looks legit. I have no idea what would cause this though.

[Iximiel]

CI failure is a segmentation fault in the Python tests, so it looks legit. I have no idea what would cause this though.

Hoping that the CI failure is something that I can control and not a mysterious change of behavior of a submodule in for some functionality of pytest, I have to massage a little pycv for that to work.

The -debug- failure needs some investigations.

The intel problem I would say that it is out of scope about this PR (unless drr talks to python):

/home/runner/work/plumed2/plumed2/regtest/drr/rt-extract2dpbc/tmp
Checking for boost_serialization dependency
Checking for drr module
FAILURE
Diff for eabf2dpbc.czar.grad:
24604c24604
<  1.623156204 1.064650844 49.200199175 19.765836219
---
>  1.623156204 1.064650844 49.200199175 19.765836220

---

At this point, can you separate again the changes in #1348 between the ones that needs 3.10 and the ones that don't (like the manual change and the one in SELECTED_ATOMS), so we can accept at leas those until the 3.10 issue is solved

Can I pr into this branch on your fork?

[Luthaf]

At this point, can you separate again the changes in https://github.com/plumed/plumed2/pull/1348 between the ones that needs 3.10 and the ones that don't

I'll do that.

Can I pr into this branch on your fork?

Go for it, you should even be able to push directly to it (or re-create a new PR if this is easier for you!)