Sort compound_finder SVs prior to processing

[alkc]

Description and reviewer info

Currently compound_finder.pl reads all SVs into a perl hash and later iterates over the keys as-is when resolving compounds. As perl hashes are unordered by default this might lead to confusing diffs when comparing two runs side-by-side.

This fix applies a simple sort to the keys in the hash.

Type of change

• Documentation
• Patch
• Minor change
• Major change

Checklist

• Self-review of my code
• Update the CHANGELOG
• Tag the latest commit (vX.Y.Z format)

Patch

• Stub run completes without errors or new warnings
• At least one other person has reviewed and approved my code (not required for trivial changes)

Test/review documentation

Review performed by

• Alexander
• Jakob
• Paul
• Ryan
• Viktor

(Add if missing)

Testing performed by

• Alexander
• Jakob
• Paul
• Ryan
• Viktor

[alkc]

this update would probably (tests still pending) make compound finder the output stable/reproducible, but would mask how the matching SVs are actually selected in the case where multiple SVs match queried SNVs/genes.

i need to look closer at the cf code, but it's my impression that the rank score of the snv is potentially decided by the last-seen SV in the subset of matching SVs, as opposed to decided by SV selected via some more specific selection criteria.

reminds me of the issue with svdb query selecting the first best loqusdb variant in the case where many variants matched the queried variant, even if the first-best was obviously not the best match.