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.

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.