instead of using the property map interface.
A nice side-effect is that the wart of having to use property maps to loop over bonds or atom neighbors
is now gone.
This potentially breaks lots of client C++ code.
http://sourceforge.net/tracker/index.php?func=detail&aid=1968930&group_id=160139&atid=814650
In order to fix the problem, the value of the query function for atomMass queries
is being multiplied by a constant factor (currently 1000) before converting
to an int. This allows distinguishing between things like [CH4] (where the
C has mass 12.011) and [12CH4] (where the C has mass 12.000).
http://sourceforge.net/tracker/index.php?func=detail&aid=1942657&group_id=160139&atid=814650
This was handled by adding error/consistency checking to Atom.calcExplicitValence()
This includes another pretty big scale modification:
the allowed valence list for atoms (in atomic_data.cpp) can now contain a -1 at the end. If this is the case, the atom will tolerate valences above the ones listed.
This is done to allow "flexible" atoms (i.e. transition metals and the like) to accept arbitrary coordination numbers without generating errors.
update aromaticity to require unsaturation at single-atom donors
test the above two things
This is not necessarily completely stable, but all current tests pass
(once obvious changes have been made). We will just have to see where
the aromaticity changes cause trouble going forward.
