Add caalm

[vagkaratzas]

New protein annotation software for CAZyme prediciton from amino acid sequences.
PR includes the setup module needed to download models from hugging face.

The bioconda recipe review process is slow, so for now, using a pip installation (env and containers through Seqera Containers).

This is the CPU version. Will probably create a separate GPU (dramatic speed increase) one after this gets merged.

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 module conventions in the contribution docs
• If necessary, include test data in your PR.
• Remove all TODO statements.
• Broadcast software version numbers to topic: versions - See version_topics
• Follow the naming conventions.
• Follow the parameters requirements.
• Follow the input/output options guidelines.
• Add a resource label
• Use BioConda and BioContainers if possible to fulfil software requirements.
• Ensure that the test works with either Docker / Singularity. Conda CI tests can be quite flaky:
  • For modules:
    • nf-core modules test <MODULE> --profile docker
    • nf-core modules test <MODULE> --profile singularity
    • nf-core modules test <MODULE> --profile conda
  • For subworkflows:
    • nf-core subworkflows test <SUBWORKFLOW> --profile docker
    • nf-core subworkflows test <SUBWORKFLOW> --profile singularity
    • nf-core subworkflows test <SUBWORKFLOW> --profile conda

[vagkaratzas]

test_level*_embeddings, seem to change between my local machine and GitHub runners; investigating

[vagkaratzas]

test_level*_embeddings, seem to change between my local machine and GitHub runners; investigating

I did some more tests and they seem to stay the same in a system, but change depending on CPU model, probably because of non-determinism in the FAISS index search or the ESM embedding computation, and not due to a container/environment difference.

Likely causes (by the bot -I excluded one that didn't make sense for this case):

1. CPU architecture / SIMD instructions — FAISS uses AVX2/AVX-512 on modern CPUs and falls back to SSE4  
  or scalar on older ones. The floating-point operations are reordered differently depending on the SIMD   
  path, producing subtly different embeddings due to floating-point non-associativity. GitHub runners use  
  different CPU generations than your local machine. 

2. FAISS approximate nearest-neighbour — if Level 2 uses an IVF or HNSW index, the search is approximate 
  and the results can differ when the hardware SIMD path changes, even with the same query vectors.        
   
 The fact that it's stable within the same machine across Singularity/Docker/Conda confirms it's not a    
  software version or library issue — the same binary code hits the same SIMD path on the same CPU. But
  cross-platform (your machine → GitHub runner), the CPU capabilities differ, changing the low-level       
  floating-point execution path.

[jfy133]

I would put these all on one tuple, they are all related and can't be used in any other way (e.g. with .bam and .bai) - that way you don't have to do any .combine shenanigans in this case

[vagkaratzas]

Also agreed. Coming up