Fixed issue in FindPython: requested Python version was only tested to be bigger than requirement, not equal to

Standard residue names have three letters. In case of the CHARMM
dialect, also four letters are allowed. This has been neglected
when writing the terminal residue.

setting it to false by default was creating too much downstream
trouble. the proper fix for not having to waste any CPU cycles
assigning torsions (which are barely ever looked at) would be to
have GetPhiTorsion/GetPsiTorsion/GetOmegaTorsion return temporary
Dihedral objects with the same interface than TorsionHandle.
These would be created on the fly.

Thanks Marco

fixes problems for users with read-only home directories. Plus,
it's easy enough for the user to create the file when it's
needed

It seems, just looking at the number of atoms is not enough,
we also have to look at the hetatm flag. The whole element
guessing code is still quite shaky and should be improved.

The order of destruction of static objects, e.g. singletons is
arbitrary and can not be relied upon. For some versions of
Python, the singletons are destroyed after Python has shutdown.
When objects stored in the singletons have been created in Python,
a segfault is produced when they are destroyed, since the destructor
assumes a Python interpreter exists. To work around that, we register
atexit handlers to remove all references to Python objects. That's
required for the IOProfileRegistry and Conopology singletons.

- Fix for data viewer to use main ost menubar: Data viewer menu (labeled Panels) for the active data viewer window will show in the main menu bar.
- Added foxus proxy for the data viewer and its QMdiSubwindow to ensure that the data viewer panel gets the keyboard focus from the beginning.

when adding a gfx entity to the scene using scene.Add(), the time it
takes to add it is growing quadratically with the number of entities in
the scene (only in gui mode), which is caused by resizing of the table
in the sequence viewer.

message

This avoids funny artefacts on tab_old if you create a new table
tab_new in the following way and try to add new columns there:

tab_new = Table(tab_old.col_names, tab_new.col_types)

this is a follow up to 76b079d7, in which part of the problem, but not
the complete one was fixed.

Fixed a glitch in the PDBizer: if more than one set of tranfsormations & chains exist, lingand/ water chains in the entity already exist, but are re-initialsied in a call to PDBizer.Add and added again to the entity... which does not work, of course.