Support runtime cache of feature change timestamps

[cportele]

This is a follow-up to #994, which added support for the Last-Modified header for requests to a single feature. The timestamp can either be a fixed value in the configuration or taken from a feature property.

An alternative approach that would support concurrent editing via the CRUD operations (but not for cases, where the data is updated through other means) would be to

• use the startup time of the ldproxy instance as the initial value for all features;
• maintain a runtime registry with feature update timestamps that have been edited (empty at startup);
• to determine the last-modified value for a feature, the registry would be checked and the startup time would be used as fallback;
• potentially clean-up entries in the registry after some time (24 hours?).

If there are multiple instances of ldproxy in a cluster, the runtime registry would need to be shared across all containers and the startup time would need to be the startup time of the cluster.