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

Chain naming in biounit construction reserves 1.<au_cname> for the
respective AU chain with identity transform applied. As of January
2024, there are 3 PDB entries (8qn6, 8x1h, 2c0x) where the same AU
chain with identity transform occurs several times in the same
biounit. This is likely an error in the respective mmCIF files as
the resulting chains sit on top of each other. OST just names the
FIRST occurence as 1.<au_cname>.

A warning for that behaviour is also added to the documentation

This allows the mmCIF writer to save the entity_poly.type as "other"
rater than error on an unknown type.
We can do this because there is no "other" in _entity_poly.type.
Added a comment about the risks of chain_type for reading/writing mmCIF
files.