SPIKE: investigate upgrade/migrate strategy for reference data

Module tenant initialization for both first-time init and for upgrades calls the _tenant interface, and tenant parameters included in the Okapi install API call are passed to the module, including loadSample and loadReference.

As currently implemented in most modules, this will cause the module to attempt to load all reference data on module upgrade (not just new data). New records will be created if needed, and existing records (matched by UUID) will be overlaid.

Due to this, issues arise if the tenant has altered or deleted any of the reference data loaded by the module when it was first enabled. Any changes will of course be overwritten with the system default, and deleted records will be re-created.

More subtle problems arise if the record type in question has data constraints (for example, the requirement that a particular property be unique), and the tenant has created a new record of that type which causes a conflict with incoming reference data. As currently implemented, this kind of conflict causes the module upgrade to fail, potentially leaving the tenant data in an inconsistent state.

These kinds of issues would very likely also arise if an operator specified loadSample=true in an upgrade, but that is currently untested, and seems like an unlikely use case, at least for production.