This PR:

• Add ENV_LAUNCHER_SCRIPT_PATH to launcher_conf.sh: This means for scripts that are run as part of launcher.sh and within the singularity container, it is possible to find out how to launch the container again. This is useful for payu, so it can pass the launcher script along to the PBS jobs. This was tested with a payu branch that adds the launcher script environment variable to the PBS commands, so it looks like qsub <qsub-flags> -- /path/to/launcher.sh /path/to/squashfs-payu-env/bin/python /path/to/squashfs-payu-env/bin/payu-run. This removes the hack of modifying the payu python headers to point to the python launcher script.
• In a continuation of another PR which has an issue of the payu environment clashing with other conda environments, I had a go at only exposing the payu launcher script commands, now that payu didn't need a python launcher script.

Pros of restricting commands to only payu and removing any conda environment variables (so environment is not activated):

• It works with the conda/analysis3 environments without a pre-existing payu (version <= conda/analysis3-25.04), provided both modules are loaded before running any scripts/commands. This still means it wouldn't be possible to run the conda/analysis3 environment executables in userscripts in payu as the squahfs environment overlays are needed when the container in launched on the PBS node. But it'll be possible load conda/analysis3 or another conda environment on login nodes and submit payu jobs via the command line.

Cons:

• Creating virtual environments no longer work as I removed the python launcher script and activating the conda environment.. Virtual environments are used for repro testing and are built off the payu environment to reduce the size. A solution could be to have two options for modules, e.g. one that exposes all the launcher scripts for the environment and activates the conda environment, and one that just has the payu commands?
• Any entry-points will need to manually be added.