Use singularity containers for apptainer profile too

[SPPearce]

Description of feature

Singularity has split out into an open source version called Apptainer two years ago.

Currently the logic for using singularity containers for modules is hardcoded to require the use of the singularity container profile, e.g.

 container "${ workflow.containerEngine == 'singularity' && !task.ext.singularity_pull_docker_container ?
        'https://depot.galaxyproject.org/singularity/ubuntu:20.04' :
        'nf-core/ubuntu:20.04' }"

so the apptainer profile will build from the docker containers instead, which is less robust and more likely to fail. It would therefore be good to enable the singularity images for apptainer too.

This was discussed in on Slack, with this summary from Phil @ewels :

Yup, so in summary:
Short term fix to just get things working is apptainer.registry, now merged and will go out in release imminently
TODO: Medium term fix: We should write up some docs explaining about the singularity command alias and how we can trick the system to work as you described.
TODO: Long term fix: Update logic in all modules, plus all container parsing logic, plus all infra, to handle apptainer profile name 🙈
May be worth discussing using a param instead of relying on workflow.containerEngine for better future proofing / more concise code?
ℹ️ Note that Nextflow will hopefully give us a list of container names soon, meaning a significant rewrite for the nf-core download infra, may make sense to wait for that and do this all in one go

[SPPearce]

I do think that using a parameter instead of workflow.containerEngine is the neater solution, in case there are further options in the future it wouldn't require changing all the modules again.