feat: update multiqc wrapper to v1.11

[thomasbtf]

Description

Update multiqc version to v1.11.

multiqc v1.10.1 used collections.Mapping here https://github.com/ewels/MultiQC/blob/v1.10.1/multiqc/utils/config.py#L256.
This is deprecated with Python 3.10 and updated to collections.abc.Mapping in multiqc v1.11 (https://github.com/ewels/MultiQC/blob/v1.11/multiqc/utils/config.py#L270).

QC

For all wrappers added by this PR, I made sure that

• there is a test case which covers any introduced changes,
• input: and output: file paths in the resulting rule can be changed arbitrarily,
• either the wrapper can only use a single core, or the example rule contains a threads: x statement with x being a reasonable default,
• rule names in the test case are in snake_case and somehow tell what the rule is about or match the tools purpose or name (e.g., map_reads for a step that maps reads),
• all environment.yaml specifications follow the respective best practices,
• wherever possible, command line arguments are inferred and set automatically (e.g. based on file extensions in input: or output:),
• all fields of the example rules in the Snakefiles and their entries are explained via comments (input:/output:/params: etc.),
• stderr and/or stdout are logged correctly (log:), depending on the wrapped tool,
• temporary files are either written to a unique hidden folder in the working directory, or (better) stored where the Python function tempfile.gettempdir() points to (see here; this also means that using any Python tempfile default behavior works),
• the meta.yaml contains a link to the documentation of the respective tool or command,
• Snakefiles pass the linting (snakemake --lint),
• Snakefiles are formatted with snakefmt,
• Python wrapper scripts are formatted with black.

[fgvieira]

Should we instead make it as:

multiqc =1.11

So it is not fixed to patch versions.