Reject Halloween vulnerable queries on FK referenced tables

Ass opposed to fundamental changes to handle them correctly, as was discussed.

Two cases:
- Halloween vulnerable query (e.g. UPDATE t SET id=id+1) when table is referenced
- DELETE or UPDATE on referenced table with join/subquery of referencing side when action affects referencing rows

I believe the rejection is more conservative than strictly required in some cases (e.g. DELETE subquery uses referencing but not any of the FK columns) but making it precise is both delicate and, I think, offers little more benefit for realistic applications.

LBJ: NO_BUILD