This is no final product but just a first working version as a
starting point. Plenty of testing/cleanup/speedup required.

There are structures with only atoms that lie on top of each other.
This is typically a fuckup but hey, better a nice error than the segfault
that would be caused by this...

This indicates a bug that must be fixed but at least we don't run
forever.

Use a very large inclusion radius. This should not impact the exhaustivity
of the chain mapping search by much, but makes it less likely to impact
low/medium RMSD scores.

These are two independent ways to speed up the processing but they
make no sense in combination and could lead to unexpected effects.

This prepares for testing with full_bs_search where a model ligand can
no longer be too far from the actual binding site.

- separate scrmsd and lddtpli computations in separate functions
- optionally reduce the binding site search space in the model

This should not change behavior but will make it easier to speedup
binding site extraction

LigandScorer uses ChainMapper.GetRepr to match binding sites between target
and model. This commit limits the search space for model binding sites to
locations where there actually is a ligand.

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.