Simplify combined_networks structure?

[krivit]

Currently, the system is designed to, in principle, be able to un-combine networks in any order. It may make sense to instead mandate that the networks be uncombined in the same order as they are combined. This will simplify the data structure and save memory. It may also make sense to store subnetwork information not on vertices but on subnetworks (and the .subnetattr of the combined network).

uncombine_networks() can also be simplified, since we would then only need to take the .subnetcache networks and copy the edges.

This is related to #42, since it needs to assume that the uncombining is done in reverse order of the combining.

[krivit]

What if, instead of actually constructing a network object, the combined_networks class were a list of constituent networks (which themselves may be combined_networks) with some metadata that helped map vertex indices of the combined network onto the index of the subnetwork and its vertex index. Then, a suite of accessors and motifiers could be implemented that would propagate the methods for network objects in the network package onto the subnetworks.