Tooling to prevent cross-organization querying

In #394797 (closed) we'll be adding constraints related to some specific GitLab feature to enforce it does not cross organization boundaries. This issue should focus on how we can detect any query in the database that might load data related to that feature from a different organization.

For example if I'm looking up group_group_links (for checking membership) then my query should either be scoped to a single organization or no organization (ie. groups that are not in organizations). We want a way to detect queries that could give a mix of the two.

It might be necessary to add organization_id columns to certain tables to implement this kind of constraint. We need to be careful to see how such a column and where clauses related to it might impact production performance. If we default all existing rows to have organization_id = NULL then perhaps we can query it without much of a performance hit as Postgres should know not to try and use any index related to this but we might need to be careful when assessing the performance changes to specific queries.

The primary objective is to show how development in GitLab will change with isolation and how we can build automated tooling to detect new cross-organization violations as well as generate a backlog of existing violations that would be a blocker before organizations could be used for horizontal scaling.