Add hierarchy iterators as attributes of Topology

[mattwthompson]

Is your feature request related to a problem? Please describe.

ipdb> topology.molecule(0).residues
[HierarchyElement ('1', 1, '', 'JJN') of iterator 'residues' containing 5 atom(s)]
ipdb> topology.residues
*** AttributeError: 'Topology' object has no attribute 'residues'
ipdb> topology.hierarchy_iterator("residues")
<generator object Topology.hierarchy_iterator at 0x1b2d89f90>

Describe the solution you'd like

Make iterators behave on Topology the same as they do on Molecule.

Describe alternatives you've considered

Going through Topology.hierarchy_iterators("residues") is okay but not ideal.
Additional context

@j-wags:

[The intent is to have this added eventually,] but I didn’t have time to finish and test that before the 0.11 release. So now offmol.residues works but offtop.residues doesn’t yet.

[j-wags]

The implementation for this would be pretty quick, I think (just updating the getattr on Topology), but I'd need to think a bit about how I'd implement the testing. That would probably be what takes a little while.

[j-wags]

Two design points from discussion today:

• If any molecule is missing the iterator with the appropriate name, this can raise an error.
• The iterator should always return HierarchyElements first ordered by molecule, and then by HierarchyScheme sorting. So residues may be returned "out of order" according to their chains or residue numbers, because a molecule with a high-numbered residue appears early in the Topology.
• There's no requirement for HierarchySchemes in different molecules in the same Topology to have the same sorting/ID logic for HierarchyElements. So one Molecule's "residue" iterator may have tuples of (chain, name, number, insertion code), and another may just be (chain, name, number), and this shouldn't cause the Topology.residues iterator to fail.
• If a HierarchyIterator tries to give itself a name like "atoms", which would conflict with Topology.atoms, then an error should be raised