Use singularity containers for apptainer profile too

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

Start by locating the module container logic, container parsing logic, and infrastructure handling for the singularity and apptainer profiles. Review the linked Slack discussion and the existing apptainer.registry change before defining the scope. Done means the relevant modules and profile infrastructure consistently support singularity images with Apptainer.