This commit additional drops more side-effects of the presence of a
seqres record by moving all the logic to the GetSeqRes function, rather
than being generated on the fly during parsing.

Previously this was based on the absence of seqres and not being a
water, which was quite convoluted and made reading of seqres 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