feat(template): add process_low_memory resource label - #4264

…ore#11541)

* fix(trimgalore): stack process_low_memory on top of process_low

Now that nf-core/tools#4264 has merged and the pipeline-template
`base.config` defines `process_low_memory` (1 GB * task.attempt),
the trimgalore module can drop its memory ceiling without giving up
the cpu/time bands set by process_low.

Composed budget on first attempt:
- cpus    = 2     (process_low; 1 worker thread paired)
- memory  = 1 GB  (process_low_memory; ~10x observed peak_rss of ~100 MB on 30M PE)
- time    = 4 h   (process_low; ~160x observed runtime of ~1.5 min on 30M PE)

The tool itself caps trim_galore --cores at 8 worker threads, so
allocating more cpus is wasted unless paired with very large inputs;
pipelines that genuinely need that throughput can override per-process
or stack `process_high` instead. This is the conservative default
that satisfies Felix's original 100 MB / 10 min ask while keeping
existing 1-worker-paired throughput intact for typical use.

* fix(trimgalore): drop redundant process_low label

The template's process default is cpus=1 / time=4.h, which is what
process_low_memory already inherits when no other resource label is
applied. process_low's cpus=2 changes nothing useful here:
trim_galore's --cores formula (`cores = max(1, task.cpus - 4)` paired)
saturates at 1 worker thread for any cpus <= 5, so 1 vs 2 cpus gives
the same worker count. Drop the redundant label.

* fix(trimgalore): use process_medium for cpus, keep process_low_memory

Stack process_medium with process_low_memory so the cpu allocation
is enough to give trim_galore 2 paired worker threads on production
data, while keeping the memory ceiling tight at 1 GB.

trim_galore's --cores formula derives worker count from task.cpus:
  cores = max(1, task.cpus - 4)  // paired
  cores = max(1, task.cpus - 3)  // single (capped at 8)

Implications:
- cpus = 1 (default)        -> 1 worker thread paired
- cpus = 2 (process_low)    -> 1 worker thread paired (no gain)
- cpus = 6 (process_medium) -> 2 worker threads paired (~2x throughput)
- cpus = 12 (process_high)  -> 8 worker threads paired (saturates the cap)

process_medium is the cheapest band that crosses the 1->2 worker
threshold, where actual trimming throughput first improves. Useful for
real production inputs (100M+ PE) where the extra worker materially
shortens wall time; small test data won't notice the difference. Memory
stays at process_low_memory's 1 GB regardless.

Companion to nf-core/tools#4264, which adds a process_low_memory
resource label to the pipeline-template base.config. Updates the
modules resource-requirements spec to:

- list all bundled and modifier labels currently shipped in the
  template (process_single, process_low, process_medium, process_high
  and the modifier-only process_long, process_low_memory,
  process_high_memory)
- document the label-stacking pattern that the modifier labels enable,
  with an example showing process_high + process_low_memory for
  CPU-bound but memory-light tools

Also unpins the base.config link from a line range that already drifted
out of date and switches the branch reference from master to main.