Replace /bin/bash with /usr/bin/env bash

[unode]

This replaces all hardcoded /bin/bash paths to /usr/bin/env bash.

When additional arguments are given to bash (e.g. bash -ue), /usr/bin/env -S bash -ue is used instead.
The env -S functionality requires coreutils 8.30 or newer. This or a newer version of coreutils is present since Ubuntu 19.04, CentOS 8 and many others.

This PR also addresses issues with containers and Linux OSes where /bin/bash doesn't exist or where bash is installed in a different path (e.g. NixOS).
The PR should also fix partially or entirely the issues #73 #1598 and #1732

Additional potential issues remain in the files:

modules/nextflow/src/main/groovy/nextflow/executor/BashWrapperBuilder.groovy
modules/nextflow/src/main/groovy/nextflow/k8s/K8sDriverLauncher.groovy
modules/nextflow/src/test/groovy/nextflow/container/DockerBuilderTest.groovy
modules/nextflow/src/test/groovy/nextflow/container/PodmanBuilderTest.groovy
modules/nextflow/src/test/groovy/nextflow/container/ShifterBuilderTest.groovy
modules/nextflow/src/test/groovy/nextflow/container/UdockerBuilderTest.groovy
modules/nextflow/src/test/groovy/nextflow/executor/BashWrapperBuilderTest.groovy

Where /bin/bash is still hardcoded to work with different images.
In fact, some of that code is likely non-functional as, for instance, the latest busybox docker image no longer includes /bin/bash.

[pditommaso]

The PR should also fix partially or entirely the issues #73 #1598 and #1732

Sorry, can't merge this. This issue was already discussed #1598. The use of /bin/bash is a fair assumption. If the host uses a different path for the bash binary, it could be easily fixed by adding a symlink.

[unode]

As explained in the description, that's not quite true and there are many cases where this may fail, NixOS being only one. Others include systems where /bin/bash is too old or incompatible (e.g. when LD_LIBRARY_PATH is tampered with due to complicated software stacks), in which case a newer bash may live somewhere in the user's $PATH.

As for a symlink, you seem to be assuming that users will have control over /bin/bash. This is rarely the case.

The proposed PR addresses all these.

One could make a case for env -S but if that's a concern, can we discuss alternatives, such as converting all the hardcoded shebangs and identical bash invocations into a user defined path, perhaps as a command-line argument?