previously this was done with residue ChemClasses. This is set by the
compound library anyways during processing when loading a structure.
The problem: when we suddenly need info on chemical components for stuff
that is in the SEQRES but nowhere resolved in the structure. I really
tried hard to avoid the requirement for the compound library in mmcif
writing but there seems no way around.

When defining custom mmCIF entities, we should check for valid input using
the latest mmCIF dictionary

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

Right now there is only a static constructor for polymer entities

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"

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

Only relevant for resnum based alignments, i.e. enabled mmcif_conform flag

Only relevant for resnum based alignments, i.e. enabled mmcif_conform flag

This avoids silently creating invalid files if we have gaps in
oligosaccharide chains, for instance.

- Reduce the number of StarWriter objects to simplify things.
- Make construction of the actual values more expressive
  => explicitely do things like: StarWriterValue::FromString("xyz")

Unlike in the PDB, they are treated as normal polymers with type
"other". We may want to consider support for the branched type in the
future, however polymer more closesly matches the internal implementation
in OST.

Simplify splitting of randomly behaving entity into an mmCIF conform entity
The behaviour should largely stay the same

- Introduce code redundancy by removing star_base.hh again.
  It was a bad idea from the very beginning. The reader operated
  with ost::StringRef. A StringRef is purely pointer based  which is fine
  when you have external data ownership. Thats the case for reading.
  For writing you want to build up a data structure that actually holds data.
  So you want to store actual strings. Thus the introduction of StarWriter
  objects.
- Use shared_ptr instead of raw pointers
- Change function names to better follow the OST conventions