plpgsql: decorrelation rules can re-arrange PL/pgSQL subroutines

[DrewKimball]

Due to #97432, decorrelation rules can sometimes hoist side-effecting subqueries. This is problematic for PL/pgSQL, which relies on evaluation order for correctness, e.g. for making the tail-call optimization valid. Here's an example where a RAISE statement fails to execute because of this issue:

root@localhost:26257/defaultdb> CREATE PROCEDURE p(x INT) LANGUAGE PLpgSQL AS $$
                             ->   BEGIN
                             ->     IF pg_sleep(0.1) IS NOT NULL THEN
                             ->       RAISE NOTICE 'foo %', x;
                             ->     ELSE
                             ->       SELECT x;
                             ->     END IF;
                             ->   END
                             -> $$;
CREATE PROCEDURE

Time: 85ms total (execution 68ms / network 17ms)

root@localhost:26257/defaultdb> call p(1);
CALL

Time: 118ms total (execution 117ms / network 1ms)

pg_sleep returns True, so the RAISE statement should have executed here. Instead, HoistValuesSubquery fires, ignoring the guarantees provided by CaseExpr, and hoists the subquery that contains the RAISE. Since the sub-routine is no longer in tail-call position, TCO becomes invalid and the side effect is lost. #120327 will fix this behavior, but we need a more targeted, backportable solution as well.

Jira issue: CRDB-36688