Hierarchical groups

[rchristie]

Proposed new feature to allow groups to contain other groups:

The group field could have the option to add other local groups to it, not procedurally but as functional sub-groups. If any such sub-groups are added, its mesh groups and nodeset groups are automatically synchronised to be the union of those from the sub-groups, and can't be edited directly.

Applications:

1. Having multiple names for the same group e.g. annotations ILX identifier/url and string name. The primary group could be the name, but the annotation term id could be a group containing the single other group, or vice-versa.
2. Superset groups. In the vagus scaffolds we have common groups for variant branch groups A, B, C etc, but these would be more efficiently represented and stored by having the super group contain all the variant groups. Admittedly, if combined with (1), there would also be term id groups for the common branch groups.
3. The whole body scaffold may have conforming sub-meshes (i.e. collections of faces of the 3-D mesh) for most of the skin, and some internal surfaces, however it is anticipated that detailed regions such as ears or nose may be handled by embedded sub-meshes in a box host. The group of groups concept could be the way to make a single group of faces and embedded faces for the combined 'skin epidermis outer surface' group. This would likely require embedding concepts to be fleshed out and serialisable, including implicit definitions of host fields.

High-level API should allow both sub-groups and containing groups to be queried.

Most likely we would make EX version 4 write the subgroups not the mesh/nodeset groups; alternatively we could use a !# directive to add the subgroups; the mesh/nodeset groups would be read statically by old Zinc versions, ignored by new versions. Note that sub-region group connections are not currently serialised in the EX file, but could easily be added in the same way.