Future-proofing the CI against future Python versions

[Iximiel]

Description

This is the finalization of the work I did in #1363, and that @Luthaf started in #1350

This is a big PR, so a few word to explain this:

• I changed the build procedure for the python interface: the user no longer needs to install cython. The interface can installed by simply running pip install ., with no preparation steps. Or it can be build with python -m build ., but this will need the user to install the build as it is done in the CI
  • I changed the conda requisites accordigly
  • I removed a some duplicated make code that was shared by the python target and the install target forbundling the python interface at install time. That procedure is stored in the python/onlyBuild.sh file, so that modifications can propagate easily
  • The Plumed.h is a link in the python interface now (and I do a few shenanigans to make it works with make install)
  • Now the python interface is shipped pregenerated in the repository, and I added a similar check to the one that already exists for configure and configure.ac
  • added a new cythonize target in the python directory, so that the interface can be cythonized and uploaded into the repository
  • I moved the cython options directly in the pyx files as a "option comment"
  • Since I stationed for a few time on the inputbuilder test I changed the name of the test because with the "speaking" names of the tests it was easier to understand where thing were breacking
• I moved the python requirements both for building and running python things in various requirement files, this helps in propagate requirements changes into the CI, by keeping the requirements in the context of the docs/interface/module directory and makes them orders of magnitude easier to access them than digging in the CI files.
  • Using the requisites files propagates the changes also in the various docker tests
• I created an action for setting up the plumed environment in the CI, so that the configuration is shared between the linuxWF and the new pythonWF and so that modifications in configuration can be propagated with less headache
• the new pythonWF will install a basic version of plumed and then test all the python related things on various python versions. This will help when inevitably python 3.1{0..9} will go EOL in the main WF
• I decided that the main WF should run the "oldest" python version. Are you ok with this?
• There is also another difference in the tests of the python interface between the python and the linux WF: the linuxWF will test the installation by forcing cython to regenerate the pyx file, whereas the pythonWF will use the bundled generated c file with the interface, this basically test the pip version.
• I removed pycv from the configure procedure, since the requisites are handled by pip and CMake in the pycv installation/build phase

@Luthaf Are you ok with the changes in pytorch? I think I addressed your concerns in the previous PR, but I still separated them in a commit, so that they are more accessible to be checked/modified.

Target release

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

Type of contribution

• 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

• 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

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

[Luthaf]

Having these dependencies specified here instead of the CI workflow only still feels weird to me (these are mainly here for easier CI building); but I can also see a point in having it consistent with the rest of the dependencies specifications, so I'll let you make a call here!

[Iximiel]

My idea was that this requirements should only be called in the CI (or when you want to run the tests, from what I understood) the 'plain' requirements.txt is the one to be used by the user.

From your comment I feel like this is not clear enough. Do you think that if I call this "ci_packages.txt" (or "test_packages.txt") this will create less confusion?
Maybe also by adding a few lines of explanation to the md file with the instructions?

[Luthaf]

I think I understood that part, but for me such a file should not be in src, but rather in ci or .github/workflow. It does not matter too much anyway 😅

[Iximiel]

ok, then I'll move the requirements in the .ci directory
I am force pushing the change, so we might lose this conversation