fnat, lrmsd, irmsd etc. are not strictly DockQ related, they just
serve as input for DockQ

So far, the Scorer object only relied on the number of chains in
the target to decide whether to enumerate the full chain mapping
solution space or apply a heuristic. The number of chains in the
model is equally important.

The default is to rely on residue numbers for ref/mdl residue mapping

A new entity with new residue numbers is constructed for scoring

guard for the rare case when stereochemistry checks remove a whole chain

avoid KeyError when trying to figure out whether model residue is
covered by target structure