Structure metadata sharing

[gklyne]

• Support import types/views/lists/fields/etc. from another collection

[gklyne]

• Generalize collection/site hierarchy to use a "search path" of imported collections. See also next item.
• Think about implementing site data as a distinguished collection, thereby exploiting the access control framework for site metadata updates.
• NO (currently going with just _annalist_site) _annalist_core for software-defined values, and _annalist_site for local overrides?
• Refer collection management permissions (create/update/etc) to _annalist_site collection - this will make it easier to define top-level permnissions through Annalist itself, rather than relying on annalist-manager.

[gklyne]

(These comments copied from issue #15 so that issue can be closed.)

• Enumerated values are hard-wired into models.entitytypeinfo - move them to regular type/data files in site data collection?
• Currently, it seems all _annalist_site values need to be hard-wired in entitytypeinfo; maybe look to use collection "search path" logic instead (see above).

[gklyne]

Removed V0.x milestone as goals for this release have been addressed. There are some additional tasks to be revisited later.

[gklyne]

The site enumerated values are now stored as regular type values, but they are still hard-wired in entitytypeinfo to use dynamically-generated class instances from recordenum. At the present time, it's not clear that this serves any functional purpose, but might in future be used to support additional enumerated-value-specific logic (e.g. migration?).

All TODOs on this issue are now ticked off, but issue left open pending a decision on whether or not to remove the special enumerated-value logic.