Flatten bundle hierarchy

[Scooter Morris]

Atomic and Volume are good examples of this.

[pett]

The proposal is to flatten the bundle hierarchy so that no bundle installs under another bundle. There would still be some module-level hierarchy left, but only that established by a single installation unit, e.g. the atomic bundle itself makes a small module hierarchy (but no other bundle would install itself under chimerax.atomic).

The question is how much backwards compatibility to support. My feeling is that at this point there are probably no third-party extensions that import the modules that would move (e.g. chimerax.atomic.hbonds → chimerax.hbonds), so if we do this immediately it would be okay to "just do it". Nonetheless, there are two possible ways to support backwards compatibility if necessary:

1) Have the parent module put import the former-child modules and put second entries into sys.modules under their old import names. The principal downside is that this solution requires all the child modules to be imported at ChimeraX startup for the rest of eternity. By my count there are 34 such child modules.

2) Add an import hook that gets invoked when a chimerax.{atomic, map}.blah import fails and tries to import chimerax.blah and if that works put a second copy into sys.modules (like #1 does). This is cleaner in that it only happens "on demand" (i.e. an old-style import happens).

[pett]

One further note is that flattened bundles should have their major version number bumped. This will prevent ChimeraX 1.0 and earlier from trying to install them if and when they get put on the Toolshed. Also, in case I'm wrong and it turns out there are bundles that import them directly, if the bundle properly declares its dependencies the Toolshed will know that the bundle is not compatible with ChimeraX 1.1. Nonetheless, I don't think I am wrong and there will be no such bundles if we get 1.1 out the door pronto.

[pett]

Have flattened the atomic and seqalign hierarchies. Tom will flatten the map hierarchy.

I commented out the circular-dependency warning generated by the Toolshed, which I think is no longer germane to the build process we currently use.

[Tom Goddard]

I flattened map.data, map.fit, map.filter, map.series to map_data, map_fit, map_filter, map_series.