opt: generalize split-disjunction rules

A customer ran into a case where a query ran fast when constraining either of two columns to a constant, but slow (~25s) when constraining both with an OR condition (e.g. `x = 1` is fast, `y = 1` is fast, `x = 1 OR y = 1` is slow). This happened because the single-column filters could be pushed down into one input or the other of a cross-join, whereas the slow case had to defer filtering until the expensive cross-join with thousands of rows. We already have some optimizer rules that can duplicate part of a query plan and combine the results in order to efficiently evaluate a disjunction (see `SplitDisjunction`), but these only apply to relatively simple cases, where a scan or lookup join is duplicated. We should consider splitting disjunction conditions in more cases.

While a generalized SplitDisjunction could duplicate the entire sub-plan beneath the disjunction, it may be easier to use a CTE instead. This would help bound the worst-case regression due to duplicate efforts, though could pose more of a barrier to optimization. We could then rely on other rules to consider whether to materialize the CTE, or to inline it and duplicate the subplan.

Jira issue: CRDB-32869