Switch to CTest

[jngrad]

Replace the Makefile-based test driver by the CTest driver. Tests can now run in parallel with make unit_tests -j8.

[jngrad]

The CTest tool is described in more detail in the the "Mastering CMake" book, chapter Testing With CMake and CTest. The CMake community provides detailed instructions on Using CTest and CDash without CMake. I skipped the CDash part, since I don't have much experience with the dashboard and wasn't sure how it would integrate in GitHub Actions. Most pyMBE and ESPResSo users are already familiar with CTest, and its ASCII-based reporting should be sufficient for our needs.

Long tests are sorted by decreasing runtime. This way, the first time make functional_tests is called, the CTest scheduler runs the slowest tests first. This cuts the samples job runtime from 50 min down to 20 min (logfile 29390808749). This only works the first time, though! For end users who run make functional_tests or make tests multiple times, the test order may not match with the order specified in testsuite/CTestTestfile.cmake after the first run. That's because the CTest scheduler keeps track of test statistics in testsuite/Testing/Temporary, such as runtimes and test failures, and uses this information to improve future runs. For example, failed tests in the last run will be scheduled to start first the next run, so as to give users rapid feedback on whether their latest code changes have fixed the failing tests.

While this PR adds CMake as a dependency, I have no intention of making pyMBE a CMake project. CMake is required by CTest, but anyone can edit the testsuite/CTestTestfile.cmake without the need to be familiar with the CMake syntax. In fact, variables like CMAKE_CURRENT_SOURCE_DIR are not even available, since we don't have a CMake configuration stage. This can come as a surprise to experienced CMake users.

[pm-blanco]

Thank you very much for this PR and the useful links @jngrad! I did some testing in my office computer and the new framework for tests seems to work very well and is way faster than before, which will save both on our Github quota and on the time spending debugging code. I also think that it should be clear from your notes how to add new tests with the new framework, but @paobtorres should take a look into this PR since she is the one that is going to develop tests in the near future.

I think that we should note in the requierements that cmake is a dependency only for testing. Since we are working in a virtual environment it should in principle not be a problem to have it installed by default, but just in case it might be a potential issue for some of our users. I added a similar note on tqdm which is actually only needed because we use it in some of our sample scripts

[pm-blanco]

Looks good to me, thank you for the detailed explanation @jngrad. I took a look into poetry and I agree with you: it is an interesting tool but not what we need at the moment. I do not think that it is worth for now to add another layer of complexity to our library. Thanks for the refactoring of the HH tests, the ut.TestCases sounds like a quite convenient framework. We can try to use it more for our other tests!