enhance GROMACS easyblock to improve control over PLUMED support (native vs. patching)

[ostueker]

Since GROMACS 2025 one can compile GROMACS with a PLUMED interface without patching it by setting CMake option -DGMX_USE_PLUMED=ON.
Applying PLUMED patches to GROMACS 2025 is still possible in order to get the latest PLUMED functionality.

This PR adds a fourth option 'patch' to the extra-option plumed.

• plumed = None (default) auto detects whether PLUMED is available and do the same as plumed = True
• plumed = True sets -DGMX_USE_PLUMED=ON for GROMACS >= 2025 or try to patch GROMACS with PLUMED's patches for older (<=2024.x) versions (depends whether the loaded version has patches for that version of GROMACS
• plumed = 'patch' will try to patch GROMACS with PLUMED's patches regardless of the GROMACS version
• plumed = False will disable PLUMED functionality, even if it is found (neither apply patches nor set -DGMX_USE_PLUMED=OFF for GROMACS >=2025

<edit>improved logic is here</edit>

I think that's the best of both worlds. It behaves like before for older GROMACS releases (before 2025) and takes the minimal-invasive route (avoiding to patch) when set to None or True.

[jhmeinke]

Wouldn't it make more sense to use, e.g., plumed = 'native' to enable the native support for GROMACS 2025 and newer? I admit it's a bit more invasive, but with this PR, plumed = True|None results in limited functionality for PLUMED in GROMACS >= 2025 compared to older versions, which might be unexpected.

[ostueker]

I quite like the idea of introducing a setting plumed = 'native' which would make clear which PLUMED integration is being used.

As far as I can tell, the plan is for GROMACS to gradually support most PLUMED use-cases via their native API. GROMACS 2025 with a limited native PLUMED-API was just the first step into that direction.

PLUMED's own description of their gromacs-2025.0 patch is:

This patch previes (sic) extra features to be implemented in the official PLUMED integration in the next GROMACS version

I think the setting that requires the most thought is plumed = None (i.e. the default), especially taking future releases (2026, 2027, ...) into consideration.
What should happen when PLUMED has been added as a dependency but no plumed = [True|'native'|'patch'] has been set?

I argue that easybuild should use the least-invasive method, which means choosing plumed = 'native' for GROMACS 2025 and newer and falling back to plumed = 'patch' for older versions for backwards compatibility.

Since their 2020 release, GROMACS validates the checksum of the release during the build-process and will modify the GROMACS version string if the checksum does not match the official release.

Overall plumed = 'native' will be the most versatile option because:

1. When built with native PLUMED support a single GROMACS module can be used with different versions of PLUMED modules as long as $PLUMED_KERNEL points to a $EBROOT_PLUMED/lib/libPlumedKernel.so. (i.e. PLUMED can be defined as a build-dependency and not a hard dependency)
2. The compiled gromacs binaries get the badge of being an official release.
3. Functionality of native PLUMED support will soon catch up to support most common use-cases.

And to serve the needs of users who will need the latest PLUMED features which are not yet supported by the native PLUMED API, we can provide modules with plumed = 'patch' that are then linked to a specific version (module) of PLUMED.

[ostueker]

Commit 82a0da5 addresses @jhmeinke 's comments.

New logic is now:

• plumed = 'patch' will try to patch GROMACS with PLUMED's patches regardless of the GROMACS version
• 🆕 plumed = 'native' sets -DGMX_USE_PLUMED=ON for GROMACS >= 2025
• plumed = False will disable PLUMED functionality, even if it is found (neither apply patches nor set -DGMX_USE_PLUMED=OFF for GROMACS >=2025
• plumed = None (default) auto detects whether PLUMED is available and
  will use native PLUMED support where available (GROMACS >= 2025) or fall
  back to patching for older versions.
• plumed = True behaves like plumed = 'patch' and could probably be deprecated.