Add a module shell sub-command to open an interactive shell in a temporary module environment #719

Loading modules alters the current shell session: every module loaded stays in effect until explicitly unloaded or purged, and anything else that happened in between (manual environment changes, modules loaded by scripts, automatic dependency loads) accumulates in the same session. Users who want to try a software stack, run a one-off task with a different toolchain, or compare two environments, have to remember what they loaded and undo it by hand afterwards. Mistakes here are a classic source of "it worked yesterday" reports.

Other environment management tools offer a different interaction model for this: guix shell pkg... and nix shell start a new interactive shell where the requested packages are available, and leaving that shell restores the original environment untouched. spack env activate, Python virtual environments or conda activate follow a similar idea of an explicitly entered and left scope. People coming from these tools look for the same thing with module. Modules already provides envml to run a single command in a modified module environment, but nothing for an interactive session.

The need is for a module shell sub-command that spawns a new interactive shell in which the given modules are loaded on top of the current environment (or on top of a purged or restored environment when asked), and that returns to the unchanged calling session when the user exits that shell. Expected properties:

• the module specification syntax accepted by load, including variants and the actions envml understands (purge, restore, unload, switch), applies,
• the spawned shell is the user's current shell by default, with the Modules initialization active so module commands keep working inside it,
• the prompt or an environment variable makes it visible that the session is a temporary module shell, and ideally which modules it was started with,
• nesting works, so a module shell can be started from within another one and exited level by level,
• exiting leaves the calling shell exactly as it was, whatever happened in the temporary shell,
• a command can optionally be given to run in that shell instead of an interactive session, converging with what envml provides.

This would give users a safe, explicit way to step into and out of a module environment, in line with what other tools in the ecosystem offer, and would make experimentation with software stacks less error-prone.