Add support for locking clauses in SQL

[elprans]

This adds parsing/codegen bits. The resolver needs to learn to push the locking_clause down to constituent elements of the inheritance union.

[aljazerzen]

Wait, this is not a sound approach.

If we compile this:

SELECT name FROM "User" WHERE id = $1::uuid FOR UPDATE

... to this ...

WITH
user_inh_view AS (
  SELECT ... FOR UPDATE
)
SELECT name FROM user_inh_view WHERE id = $1::uuid

... PostgreSQL will lock all rows of the base table, not just the one selected by the where clause.

[msullivan]

Hm. Should we just document then that locking clauses only work sensibly for non-inherited types without access policies?
Which is probably fine anyway, for queue-like flows?

[aljazerzen]

That would work.

But we'd have to modify code for compiling inheritance CTEs, because currently we do it unconditionally - even if object has no access policies, we call into the pg_compiler and generate inheritance views, which then turn out to be very verbose no-ops. Also when access policies are disabled, we generate inheritance CTEs unconditionally, even if it is just a select from single table.

[aljazerzen]

The decision here (that me and Elvis made yesterday) is to first support FOR UPDATE/INSERT/... only object types / link tables that don't have sub-types and don't have access policies.

I'll start work on this.

[aljazerzen]

Ok, I've implemented our restrictions. This can be reviewed.

This PR should also improve resolver & query performance, because it skips creating inheritance CTEs or access policy CTEs when they are not needed.

I still have to add tests that check if locks are actually obtained as they should be.