Enh/create wrapper

When an "official" FSL distribution is installed via the fslinstaller script, wrapper scripts for all FSL executables are created in $FSLDIR/share/fsl/bin/, so that all FSL executables can be added to the user $PATH without all executables in $FSLDIR/bin/ being added.

The new wrapper creation/removal scripts are located in the share/fsl/sbin/ directory - the intent is that the pre-unlink.sh and post-link.sh scripts of a FSL conda recipe will call these scripts during installation/removal of a FSL conda package.

Note that thhis MR includes a few rudimentary tests, and CI infrastructure for automatically running those tests (and integration with the fsl/fsl-ci-rules logic for automated conda builds).

Background

I think this is currently the best option out of the ones that have been discussed (in the related [non-existent, but perhaps should be for future code changes] gitlab issue). To make things clear, we need a solution which supports:

• "Official" installation of a full FSL distribution (via the future fslinstaller)
• Direct installation of a sub-set of FSL into a user-managed conda environment, via conda install

The problems we are trying to solve are solely related to official FSL installations:

• Not clobbering the user $PATH with non-FSL commands that are installed into the same $FSLDIR/bin/, such as python, pip, conda, tcl, etc
• Running FSL python commands in isolated mode, so that other Python libraries available in the user's environment do not clobber the Python libraries installed into $FSLDIR

Generating a "wrapper script" for every FSL command, and installing those wrapper scripts into an isolated directory allows these problems to be overcome:

• The user can add $FSLDIR/fsl/share/bin/ to their $PATH instead of $FSLDIR/bin/
• Wrapper scripts for Python commands can explicitly pass -I to the python interpreter so that it runs in isolated mode

Other proposals which were discussed and rejected:

• Install everything directly into $FSLDIR/fsl/share/bin/
  • Would require all FSL scripts which refer to $FSLDIR/bin/, which would be a fair amount of work, but is possible, and hence not a show stopper
  • Would break third-party/user scripts which refer to $FSLDIR/bin/
  • would potentially have library linking issues, so would possibly need the Make system to be adjusted to be able to install into either $FSLDIR/bin/ or to $FSLDIR/fsl/share/bin/, which could get messy
  • Not "officially" possible for python projects (from what I could tell), so we would need to manually mv/cp python entry points from $FSLDIR/bin/ anyway, which feels just as hacky as a wrapper script
• Sym-link rather than use wrapper scripts
  • Does not solve the python isolation problem, nor the problem of long hashbangs (although the latter could be considered a problem for the user)