Fix languageserver errors

[dialvarezs]

This PR solves errors/warings reported by the Nextflow language server.
Mostly reused variable names and unused variables.
Additionally, I applied module updates that include error fixes.

PR checklist

• This comment contains a description of changes (with reason).
• If you've fixed a bug or added code that should be tested, add tests!
• If you've added a new tool - have you followed the pipeline conventions in the contribution docs
• If necessary, also make a PR on the nf-core/mag branch on the nf-core/test-datasets repository.
• Make sure your code lints (nf-core pipelines lint).
• Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
• Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
• Usage Documentation in docs/usage.md is updated.
• Output Documentation in docs/output.md is updated.
• CHANGELOG.md is updated.
• README.md is updated (including new tool citations and authors/contributors).

[prototaxites]

Two PRs that fix language server errors in modules:

nf-core/modules#7432
nf-core/modules#7431

[dialvarezs]

Should I also format the local modules and subworflows with the LSP formatter as part of this PR? What do you think about that @jfy133?

[prototaxites]

Should I also format the local modules and subworflows with the LSP formatter as part of this PR? What do you think about that @jfy133?

IMO unless it's something we can enforce (e.g. through a linting check) it's probably not super important as future PRs might change this?

[dialvarezs]

Should I also format the local modules and subworflows with the LSP formatter as part of this PR? What do you think about that @jfy133?

IMO unless it's something we can enforce (e.g. through a linting check) it's probably not super important as future PRs might change this?

Sure, you're right on that, using a linting check would be better to keep a consistent style over time.