`omm_compute`'s CPU platform thread allocation persists across Protocols

From @Lumber1432 in #1670

when running this simulation on the compute node of the HPC system, I get some strange behavior. No matter how I try to get the process to use all cores available on the node, the process only ever uses a few (2, maybe 3 cores) to run the simulation. The only way I have been able to circumvent this has been by creating the SolvenUnit manually and running it separately. The process then uses all cores available. I have not tested, but assume the same would happen with the VacuumUnit. I was wondering if this is intended behavior.

Looking into it a bit more, it looks like calling setPropertyDefaultValue persists within a single Python call: https://github.com/OpenFreeEnergy/openfe/blob/main/openfe/protocols/openmm_utils/omm_compute.py#L83

This causes a bit of an issue where one might want to set the number of threads for an AHFE or RHFE simulation to be 1 in vacuum and N in solvent. In those cases, either you have to set OPENMM_NUM_THEADS to a non-1 value, and then your vacuum simulation is very slow, or you set it to 1 (or don't set it) and your solvent simulation is very slow.

What we probably need to do is change it so that we take in a max thread that is optionally defined by Protocols so that you have os.getenv(OPENMM_NUM_THREADS, max_threads) style logic.

Start with openfe/protocols/openmm_utils/omm_compute.py around line 83 and inspect how setPropertyDefaultValue is used across Protocols. Reproduce the thread-setting behavior in vacuum and solvent simulations, then verify that a per-Protocol thread limit does not persist between simulations and that each uses its intended allocation.