Add separate -TMD parallelization tag for the MTD stage

[MakarSaviak]

I found a small -T / parallel MTD CPU allocation issue in CREST 3.0.1 and made a minimal fix here.

In my CREST-NCI/GFN-FF tests, a large -T value was useful for the post-processing stage, but it also slowed down the MTD stage because the parallel MTD workers were not assigned CPU resources cleanly. This small fix adds an additional -TMD flag, allowing the number of CPU resources used for the MTD stage to be set separately from the global -T value. Since 3.1.0 is still being finalized, maybe this logic would be useful to port into the refactor.

For example, in my case -T 128 significantly accelerated post-processing because many conformers had to be handled, but it increased the MTD runtime from a few hours to days. On the other hand, -T 6 was optimal for running 6 GFN-FF MTD trajectories, but too slow for the conformer post-processing step. With the separate -TMD flag, both stages can use more appropriate CPU settings.

[MakarSaviak]

While validating this PR, I found a separate mismatch between the documented iMTD-GC behavior and the compiled nonlegacy implementation.

The CREST literature states that, when a lower-energy conformer is found, the procedure is restarted from that conformer. In the code, CREGEN correctly updated env%ref, but the local mol passed to subsequent MTD iterations was initialized only once before the loop. Consequently, later iterations reused the initial reference geometry instead of the newly found minimum.

The two latest commits resolve this by refreshing

call env%ref%to(mol)