Disable module load, unload, ... invocations via wrapper

[SeanBryan51]

This change disables module commands that modify the environment via a wrapper when running a custom build script. This avoids preprocessing the custom build script for module statements which may produce an invalid bash script. This also allows for module commands that do not alter the environment to be executed as we only disable a subset of subcommands in the wrapper.

Fixes #249

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.38%. Comparing base (59910ed) to head (6d3436a).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #257      +/-   ##
==========================================
- Coverage   72.81%   72.38%   -0.43%     
==========================================
  Files          18       18              
  Lines         982      967      -15     
==========================================
- Hits          715      700      -15     
  Misses        267      267              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[SeanBryan51]

Some problems that I've encountered:

1. Scripts that use #!/bin/bash do not find the wrapper function but scripts that use #!/bin/sh do.
2. Currently we source the environment_modules_wrapper.bash script to define the wrapper function when executing a custom build script. However custom build scripts may source system wide scripts and overwrite the wrapper function, e.g. the build script for the main branch of CABLE contains . /etc/bashrc which redefines the original module function.

[SeanBryan51]

After discussing with @ccarouge, we have decided to add support for spack and to deprecate support for legacy CABLE build systems in benchcab. This adds the requirement that users will only be able to test benchcab on branches that can be built by spack. ACCESS-NRI will help with transitioning legacy build systems to use the latest build system compatible with spack.

Moving to spack will solve existing issues around supporting bespoke build scripts (e.g. #244, #249). This is the best way forward considering support for legacy build systems is a temporary that will be deprecated sooner or later.

Closing this PR.