Streamline CI testing

[rkingsbury]

Our GitHub continuous integration (CI) tests attempt to strike a balance between comprehensiveness (platforms, python versions, etc.) and speed to facilitate rapid iteration. Currently we have a test workflow that runs on every push to a PR and a test-comprehensive workflow that runs whenever a PR is merged into main. The difference between the two is the number of platforms and python versions that are tested.

Several recent PRs (#258 , #277 ) greatly expanded the scope of our unit tests for activity coefficients with different salts (and caught several bugs in the process), but these changes increased the time it takes to run typical CI tests on a PR (the test workflow) from ~1-2 minutes to 15-20 minutes.

This is not an ideal situation. While I like the comprehensiveness of the parameterized tests, I also appreciate the value of FAST CI tests when one is working on a PR.

We should review

1. Our Github workflow strategy (e.g., test vs test-comprehensive workflows, no. of parallel tests, etc.), and
2. The parameterization of the salt / activity coefficient tests

To make sure that all combinations are necessary and to find a better balance between rapid testing within PRs and comprehensive testing when new changes are pushed to main.

[rkingsbury]

@vineetbansal I would welcome your perspective / advice on this. In particular, it would be helpful if you could guide us on:

• the strategy (e.g., how many platforms to test in a PR vs. before a verisoned release)
• use of pytest-xdist to parallelize tests (which we currently do, but sometimes causes failures for a non-obvious reason)
• whether it's possible to parameterize certain test cases to run only under certain GitHub workflows. For example, in test_activity.py, some tests evaluate many similar cases, just with different numbers. If there are a total of, say, 10 cases, is it possible to trigger just one of them in a PR CI and trigger all of them in a more comprehensive GitHub worfklow?

In parallel, @SuixiongTay and @YitongPan1 could help critically evaluate all the different tests in test_activity.py and consider whether we really need them, since some of them are really more like benchmarks (comparing our code output to experiment, which should be close but not an exact match, and we are about to have a separate benchmarking suite.

[rkingsbury]

Related, our test-comprehensive GitHub action is now failing with

error: No virtual environment found; run `uv venv` to create an environment, or pass `--system` to install into a non-virtual environment

I'm not sure about the cause.