Only using contacts that are within a certain distance threshold in the target
does not penalize for added model contacts. If set to True, this flag will
also consider target contacts that are within the specified distance threshold
in the model but not necessarily in the target. No contact will be added if
the respective atom pair is not resolved in the target.

Make sure that the mmcif info object has all branch link info, also
the ones connecting  atoms that are not resolved in the structure.
In general, this commit avoids that there is explicit reference to the
underlying structure in the info object, i.e. no actual AtomHandle objects
are stored in there just the raw info from the mmcif file.

Building the connectivity is delegated to MMCifReader.Parse

The Scorer object provides two mappings. The default mapping which is
QS-score based and the rigid_mapping which is RMSD based.
The rigid_mapping is now the basis for global superposition based
scores such as RMSD and GDT. And here's the thing, OpenStructure got
a brand new GDT implementation! Scanning of best possible superpositions
is a bit simpler than in LGA but the results are similar.
Benchmarking against CASP15 TS models returns GDT_TS score where 99.2%
are within 3 GDT points with the LGA results and the maximum observed
difference is 7.39. There is a tendency for slightly lower scores in
OpenStructure meaning LGA sometimes found better superpositions.

BUT: Oligo/RNA support comes for free in the Scorer object!

The property didn't hold what it promised in the documentation and
had undesired sideeffects and collided with the fault_tolerant property
when loading PDB files.

Numpy support in C++ enabled features at two points:
Efficient way of setting positions in entity handles or setting meshes
in gfx.PrimList.

Support for newer numpy versions would've required an effort to implement.
As far as I know, no one uses these features (fingers crossed) so let's just
dump numpy alltogether to simplify the build system.

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.