If all residues in a chain are saccharides in some form, the
respective _entity.type should be "branched"

Minimum length for a chain in the target structure
to be considered in chain mapping. The chain mapping algorithm first
performs an all vs. all pairwise sequence alignment to identify
"equal" chains within the target structure. We go for simple sequence
identity there. Short sequences can be problematic as they may
produce high sequence identity alignments by pure chance.

BUT: if you're scoring peptides or short nucleotides, you
really want to be able to reduce the default thresholds
(pep: 10, nuc: 4)

Right now there is only a static constructor for polymer entities

uint8_t got interpreted as char, it's integer now

Some ligands like YUT (in CAMEO 2023-12-30_00000023/8G9C) have a huge
number of isomorphic mappings and cause CAMEO to run out of time in the
scoring (and fail horribly). This allows to limit how much time is spent
listing all the isomorphisms. 100000 (1e5) seems reasonable and ensures
the scoring completes in minutes. Computing RMSD with SCRMSD is a bit
faster and 1000000 (1e6) should be OK.

New unassignment reasons are introduced as well.

This was fixed in commit cd701347,
seqres is now always read.

The MMCifWriter stores globally the types of all residues in a structure.
We do a consistency check that the same residue name always has the same
type. However, there were special cases that we observed in the PDB. One
example is entry 2YHX which has plenty of UNK. UNK is 'L-PEPTIDE LINKING'
according to components dictionary. However, OST reads that info from the
components dictionary AND checks whether there are additional unknown atoms.
If yes, ChemClass is set to UNKNOWN which results in _chem_comp.type OTHER.
In the case of 2YHX we now have a mix of "L-PEPTIDE-LINKING" and "OTHER".

The added heuristic allows such a mix of two type, if one of the types is
"OTHER" and then stores the one that is NOT "OTHER". In this case
"L-PEPTIDE-LINKING"

no documentation or fancy features yet

Before, we already opened a file and the respective stream at
Writer initialization. This is weird when Write never gets called and
and empty file remains on disk. Furthermore, Write just wrote to a stream.
That stream was never flushed, so in principle you potentially called
Write but even after completion, the file is not necessarily written
to disk. Now, the file gets opened in Write, everything is written
to the respective stream and once done, the destructor of the stream
ensures that everything concludes.

IOProfile was never used in any of the functionalities in MMCifWriter