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

Before it just complained that the compound library was created with
an unsupported version of OST while in fact it could have been an empty or
even random file. Now it says:
Exception: Could not read OST version from loaded SQLITE DB - no valid
CompoundLib

required by prody/biotite

Reduces insane amount of compiler warnings. Inheritance from std::iterator
template was used to define traits of an iterator. Cool people define these
traits directly nowadays.

That's the minimum length for a peptide chain to be considered in chain
mapping

DOD is water too! This must be written in the chem_comp category.
Otherwise we're ending up with an invalid mmcif file. Instead of
just hardcoding, we now add whatever monomer id we observe in any
of the residues.

For predictable behaviour, providing MMCifWriterEntity objects has
the following restrictions now:

- Only allow MMCifWriterEntity of type polymer
- All chains in ent that are of type polymer must be assigned
  to exactly one of these entity_info objects and must match the SEQRES
  (MMCifWriterEntity::mon_ids)
- All chain names that are assigned to entity_info must be valid chains
  in ent

Until now, the actions were failing with somewhat cryptic messages
raised from arbitrary locations. This one should be more user-friendly.