Right now we standardise on timestamps.
For backends that are not timestamp based, I provided a workaround that uses Memcached to observe changes in the hash and provide that moment in time as the timestamp.
Let's invert this and instead use hashes as standard. Where needed we can trivially hash the timestamp value (trivial server-side, not client-side, but we won't need it client-side).
The only thing we need to do client-side is the equivalent of `max()`. Basically a cross-browser deterministic way of combining hashes into something new that is ideally not much longer than a single 7-10 character SHA-1 substring would be. Some basic function that does something like Java's String.hashCode and combines it into a new hash should do the trick.
Advantages:
* No more cache bloat to "observe" changes. This has more than once caused outages or high amounts of cache misses when we store the hash wrongly or under the wrong fragmentation context.
* No more ResourceLoader deployment bugs where changes don't propagate through cache if a module A's 10AM change is deployed after module B's 11AM change (due to `max()` remaining the same).
The latter includes situations like EventLogging using a fake timestamp of epoch+revisionid. Which is ever incrementing properly, but does not play well together with other timestamps.