Add created/updated metadata for Resources in local KB

Purpose:

To enable users to easily identify resources that have/have not changed in the local KB within a time period, support the created/updated metadata (as already supported on Agreements and elsewhere). Include display of the metadata.

Implementing searches based onthis data will be the subject of a separate story

User story statement(s):

As a e-resource librarian
I want to see the date and time that a resource was created/updated
so that I can easily tell when a resource was created/updated

Scenarios:

1. Scenario:
   • Given a new resource
   • When the resource is created
   • Then the date and time of creation will be recorded
   • AND the date and time of update will be recorded 
2. Scenario:
   • Given an existing resource
   • When the resource is updated
   • Then the date and time of the update will be recorded
3. Scenario:
   • Given a Package in the local KB
   • When I view the package in the UI
   • Then the updated/created metadata display will be included under the main heading (as used elsewhere in the app)
   • 
4. Scenario:
   • Given a Title in the local KB
   • When I view the title in the UI
   • Then the updated/created metadata display will be included under the main heading (as used elsewhere in the app)
5. Scenario:
   • Given a PCI in the local KB
   • When I view the title in the UI
   • Then the updated/created metadata display will be included under the main heading (as used elsewhere in the app)

Additional information

If we consider resources in the local KB to have a hierarchy then a change to something lower in the hierarchy should be considered an update to any objects above it in the hierarchy and therefore result in the last updated date/time being updated. The hierarchy being (top to bottom)

Package -> PackageContentItem -> PlatformTitleInstance -> TitleInstance

Updates to a Coverage should result in an update to the last updated date on the object to which the coverage applies

Updates to an identifier should result in an update to the last updated date on the object to which the identifier applies

The requirements for objects to count as updated on changes to identifiers/coverage should be put to one side for the moment, but we should not remove any logic that is already in place unless something in our changes causes issues with that existing logic

Testing notes

Make sure to test situations where a sync/package ingest happens but there is no actual update (i.e. nothing changes) - ensure that last updated date not changed in that case