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

Also export the attributes where needed.

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.

Nonsense results in that context means that the model does not
cover the desired substructure in target.

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

A new entity with new residue numbers is constructed for scoring