DOD is water too! This must be written in the chem_comp category.
Otherwise we're ending up with an invalid mmcif file. Instead of
just hardcoding, we now add whatever monomer id we observe in any
of the residues.

For predictable behaviour, providing MMCifWriterEntity objects has
the following restrictions now:

- Only allow MMCifWriterEntity of type polymer
- All chains in ent that are of type polymer must be assigned
  to exactly one of these entity_info objects and must match the SEQRES
  (MMCifWriterEntity::mon_ids)
- All chain names that are assigned to entity_info must be valid chains
  in ent

Until now, the actions were failing with somewhat cryptic messages
raised from arbitrary locations. This one should be more user-friendly.

CreateBU always returns a valid entity. We already check if it's empty
separately.

This is made possible now that we have a CreateBU function.

It turns out for some reason we were reading them from chains, based on
the ChainType of the chain. This prevented extracting anything from
legacy PDB files and didn't match the documented behavior in the action.

Now extraction is based on the IsLigand flag only, and documentation is
consistent throughout. Behavior on PDB files is tested.

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

Information from https://www.iucr.org/resources/cif/spec/version1.1/cifsyntax