As a Space's Owner, I should be able to permanently clean a datum from its History

Summary: This is yet another GDPR implication: we need to give Space owners the ability to comply with the GDPR

Querki will need to allow users to remove themselves, as detailed in I should be able to delete myself from Querki. But there could also be user data in particular Spaces. What happens when a Space's member asks to be removed from that Space? This is mostly easy -- the owner removes that member, maybe deletes their Person record (not obviously needed, but maybe), and deletes any Things that contain their personal data. So far, so good.

But what about the History? The GDPR is pretty hard-assed about this topic, and wants the data to be, at least, completely inaccessible. The History is mostly hidden, but it's still technically accessible, at least to those who have the rights.

So the implication is that we need a way for the Space Owner to say, "Scrub this Thing from the History", such that, eg, going back to be previous version of this Space won't show it. That makes me twitch on a technical level, but it seems necessary in order to allow Space Owners to completely comply with the GDPR.

(This is one of those annoying features that I suspect will be rarely or never used, but the checkbox is legally necessary.)

Eric also pointed out that this would be Very Very Good To Have in certain abuse scenarios, where somebody has put unwanted illegal material into the Space.

This is a bit tricky to implement, because we can't just append a deletion record to the end of the History -- showing an earlier Version would still show the bad data.

So I think this is going to require adding a new per-Space Scrubbed Things table, a list of OIDs that have been permanently and irrevocably killed. When loading the Space, and loading the History, all events pertaining to anything on that list would be skipped.

There is a non-zero risk of unfixable data corruption if this is misused (since adding something to the Scrubbed Table needs to be irrevocable), so it should come with Big Red Warnings, confirm buttons, and maybe even a double-confirm if you try to do it to a Model. (Which I don't think is ever appropriate, but we probably need to leave the door open to allow it.)

If this should come up as an emergency, before we have time to implement it properly, probably start with the innards, and only expose it as a command-console feature.