also bwrap module installpath

[smoors]

this PR also bwraps the module installpath (and removes --installpath-modules from bwrap_eb_options as it's no longer needed).

this change is required for making bwrap work with HMNS: for a compiler module the HMNS has to know the non-bwrapped location, instead of what is passed to --installpath-modules

the main issue blocking this change was that bwrapping a module installpath causes the already installed modules to become unavailable. this is solved by copying the full module installpath to the bwrap module installpath (with overlayfs this is not necessary). the overhead of this should be fairly limited - on our systems the size is < 25MB and <2000 files.

other changes:

• update the bwrap github action to print success/failure for each individual check.
• avoid creating the modulepath directory when in --bwrap mode (before actually running with bwrap) in case the user does not have write permissions.
• avoid adding duplicate bwrap binds (with e.g. easystacks).

[boegel]

I would really like to see a review from @bartoldeman before merging this...

[Flamefire]

This part is what breaks bwrap for HMNS:
It queries the modules and uses them as software directories. Hence we get a /tmp/ebinstall/software/MPI/GCC/12.2.0/OpenMPI/4.1.4/h5py
The modules_to_install field originates in dry_run that yields "full_mod_name" for each missing module.

Not fully sure how much this is related: it installs the module file into that software folder while the software is at the correct location:
/tmp/ebinstall/software/h5py/3.8.0-foss-2022b/lib/python3.10/site-packages/h5py

There is also a module file at /tmp/testbwrap/modules/all/MPI/GCC/12.2.0/OpenMPI/4.1.4/h5py, so correct there.

So somehow the software does end up in the right location but the module file does not.