An lddt_pli_radius < radius may lead to the absence of contacts in
lDDT-PLI.

Basically allows you to just say: optimize by lDDT/QS-Score/RMSD and figure
out by yourself what strategy gives a reasonable result given limited
runtime.

Introduce GetRMSDMapping function which replaces GetRigidMapping

This is consistent with the other mapping functions that explicitely
contain score name in the function name: GetQSScoreMapping/GetlDDTMapping

Any GDT functionality has been dropped in the process. It never took off
and scoring is problematic anyways. Let's assume there is a huge complex
and you already mapped most of it. Now there is this chain which upon
superposition is 10A away and this other chain that is 1000A away.
GDT does not resolve this. They're both 0.0.

When radius > lddt_pli_radius, it can happen that the lDDT value for
lDDT-PLI is undefined because there are no contacts, and is set to None
by definition. We handle it by not assigning the ligand (for lddt_pli
only) and add a new "unassigned" reason.

Special characters in chain names, such as '.' will break things otherwise

Removing atoms from huge structures was observed to be super slow.
Reason was the removal from the spatial organizer which helps to find atoms
based on spatial proximity. The organizer is organized in buckets which
occupy a certain volume in space. Removing an element meant to iterate over
all buckets and all their items until the atom is found. However, we know
the position of the atom and thus can pinpoint the bucket in which its
expected to be. The SpatialOrganizer::Remove was therefore overloaded with
a version that accepts a position as hint in which bucket to look.
If the atom is there, delete and return. If not, call Remove without position
hint.

Pairwise distance computation for the reference distances was
performed with N squared complexity and some funny guy had the idea
to throw a 180mer at it...

One possibibility would be the use of some KD tree data structure.
However, the construction itself comes with computational cost.
The implemented solution makes use of the expected spatial proximity
of atoms in the same chain and distances are computed as follows:

- process each chain individually
- perform crude collision detection
- process potentially interacting chain pairs
- concatenate distances from all processing steps

The new algorithm has been tested and compared to the previous
implementation by randomly selecting 3 models of each CASP15 oligo
target. Global lDDT has been tested for a match within 0.0001 and
per-residue lDDT for a match within 0.001. Reason for lower threshold
in per-residue lDDT is floating point accuracy. Also for the changed
unit test, one distance difference was within floating point accuracy
of one of the thresholds (see comments there). Accuracy of 0.001 still
means that we only allow a discrepancy of one for 1000 checked distances...

Observed speedups are size dependent and range from lower 2 digit
percentages up to several fold speedup for larger CASP15 targets.
The mentioned 180mer now concludes in a few minutes as oposed to
almost a day.

Document default values for minimum peptide/nucleotide lengths

This enables tests that depend on the compound lib.

Squashed commit of the following:

commit b5bbb445
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 15:45:21 2024 +0100

    Revert "CI: test a CI failure"

    This reverts commit 494222f9.

commit 494222f9
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 15:40:47 2024 +0100

    CI: test a CI failure

    This worfklow is expected to fail with an error in
    test_ligand_scoring.py_run. If it fails it means the compound lib is
    properly setup.

commit 7d06d517
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 15:27:45 2024 +0100

    CI: download compounds after first build

commit 89edc43d
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 15:18:25 2024 +0100

    CI: use make as documented in the wiki

commit 4f94f46d
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 15:03:45 2024 +0100

    CI: try to download and build a compound lib

commit 5d16d160
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 14:55:55 2024 +0100

    CI: try to link the compound lib differently

commit 1e9803eb
Author: Xavier Robin <xavier.robin@unibas.ch>
Date:   Wed Feb 14 14:31:07 2024 +0100

    CI: try to use the group compound lib

    This is likely to fail if we don't have the right mounts...

This reverts commit 494222f9.

This worfklow is expected to fail with an error in
test_ligand_scoring.py_run. If it fails it means the compound lib is
properly setup.

This is likely to fail if we don't have the right mounts...

This test was relying on a "bad" alignment between two essentially
unrelated chains. This is no longer happening after the replacement of
GlobalAlign by SemiGlobal in commit ddfa2ab5, and the chains no longer
align meaningfully. As a result no residue names were mismatching, as
the representation of the binding site in the model no longer existed.

We removed this assumption and only replace a single residue in the
entity. This avoids depending on an alignment in this test.

Terminal residues can be weird in GlobalAlign. E.g.

AAABAAB
AAA---B

instead of

AAABAAB
AAAB---

SemiGlobalAlign produces the latter