add dedicated output channel for trimmomatic stderr log (needed for multiqc)

[jpalmer37]

Description & Reason

The Trimmomatic module does not appear to capture the standard error log (2>) that is required for parsing by MultiQC as an output. Although there is a different type of log file exposed as an output via the -trimlog command line parameter, this trim log is quite different than the standard error log and is not parsed by MultiQC based on my own testing and the MultiQC docs on Trimmomatic.

My hacky workaround right now is adding ext.args = "2> trim_out.log" to the modules.config file, but it feels improper because of the limited control of file naming and how this stderr log gets captured in the same output channel as the trim log. (Are people using a different approach to capture this log for MultiQC? I am happy to reject this PR if there is a clean workaround that I am not aware of.)

My proposed changes separates the stderr log (needed for MultiQC) and trim logs into their own separate output channels. If this gets incorporated, MultiQC report generation becomes cleaner:

ch_multiqc_files = Channel.empty()
ch_multiqc_files = ch_multiqc_files.mix(TRIMMOMATIC.out.log.map{ it -> it[1]})

[SPPearce]

This should require updating the nf-test snapshot, to test the log outputs.

[jpalmer37]

This should require updating the nf-test snapshot, to test the log outputs.

Pardon my inexperience with the nf-core testing workflow. Trying to catch up currently. How can I help out with this?

[SPPearce]

Try running nf-core modules test trimmomatic --update; this should update the snapshot file to check the fact that the outputs have changed.

[SPPearce]

Bump.