sql: check for multiple mutations to the same table by triggers

[DrewKimball]

sql: refactor some cascade/trigger logic

This commit refactors some of the logic shared between cascades and
AFTER triggers. This will make the following commit easier to understand.

Epic: None

Release note: None

sql: check for multiple mutations to the same table by triggers

There are currently some situations where a query that modifies the
same table in multiple locations may cause index corruption (#70731).
To avoid this, we disallow query structures that may lead to a problematic
combination of mutations.

Triggers require special handling to make this check work, because they
can execute arbitrary SQL statements, which can mutate a table directly
or through routines, FK cascades, or other triggers. BEFORE triggers on
the main query "just work" because they are built as UDF invocations as
part of the main query. AFTER triggers and BEFORE triggers fired on
cascades are more difficult, because they are planned lazily only if
the post-query has rows to process.

This commit adds logic to track invalid mutations for both types of
triggers. We now propagate the "ancestor" mutated tables whenever planning
a post-query, so that any triggers planned as part of the post-query
can detect conflicting mutations. See the "After Triggers" section in
statement_tree.go for additional explanation.

Informs #70731

Release note (bug fix): Previously, it was possible to cause index
corruption using AFTER-triggers that fire within a routine. In order
for the bug to manifest, both the AFTER-trigger and the statement that
invokes the routine must mutate the same row of a table with a mutation
other than INSERT.

[blathers-crl]

Your pull request contains more than 1000 changes. It is strongly encouraged to split big PRs into smaller chunks.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is