Support doing DML in READ REPEATABLE transactions

[msullivan]

The big thing that is preventing us from doing writes from READ REPEATABLE transactions is the spectre of #2875, where conflicting data could be inserted into related types in separate transactions, because both transactions are operating on a snapshot taken before either transaction started.

Some possible approaches:

1. READ REPEATABLE DML safety inference. Allow doing the DML if we know it doesn't require looking at other types for exclusive conflict checks. Pros: Easy to do, no cost. Cons: Doesn't solve whole problem.
2. Shadow tables? Have extra side tables for the parent types containing just the fields used in exclusive constraints. When inserting into an object, you would also insert into the shadow tables for it and all its ancestors. Pros: This would let us enforce the constraints just using UNIQUE constraints with no messing about. Cons: likely to be expensive and a decent amount of work.
3. Try to use pg_try_advisory_xact_lock with a data-derived key to explicitly detect when there is a conflict. We could potentially raise either a ConstraintViolation or a SerializationError; we'd need to think about it. Pros: Implementation should be lightweight, doesn't require a data model change. Cons: Deriving the key will be hacky, potentially slow. Just feels dodgy overall.

I think something like 3 is probably the right approach here.

I was hoping that it would work to put the lock in a trigger, but it doesn't, so we get to extend the conflicts machinery some more.