Add timestamp to pconfig

Here's a proposal for review for adding timestamps to pconfig.

There is still one case that is not resolved properly by this. If a pconfig value is changed on HubA but is deleted from HubB before the update from HubA arrives, HubB will update with the change from HubA.

To some extent this is an edge case - since in core right now, deletes of pconfig values are not being broadcast as far as I can tell. So what this proposes is still an improvement. [fixed]

I think I have a way to process deletes without adding a "deleted" column to the table. We could use a category of "hz_deleted" and a key name of "category:key" and a value of the timestamp of the delete. If a category:key is SET or UPDATED, delete the "category:key" from the "hz_deleted" family. If we're worried about overflow of the "category" column, we could consider a hash (eg. MD5) for the key. [implemented using hash - sha256]

Anyway, thoughts / discussion welcome as usual. Besides checking for syntax errors, I haven't done any testing with this - before I walk too far down that road and invest too much in that direction, I want to make sure this is the basic direction we want to take.