fix: graceful error for deeply nested expressions instead of stack overflow

[nathanb9]

Which issue does this PR close?

• Closes Deep WHERE clause overflow stack in select_to_plan via derived expr::clone #22936.

Rationale for this change

A flat WHERE col = 0 OR col = 1 OR ... chain builds a very deep BinaryExpr tree. The tree is built iteratively so building it is fine, but later recursive passes (derived Expr::clone, Drop, the optimizer) overflow the stack and abort the process. sqlparser's recursion_limit only guards nested expressions; flat equal-precedence chains are parsed iteratively and bypass it. We should fail gracefully with a planning error instead of crashing.

What changes are included in this PR?

• Track expression-tree depth in the sql_expr_to_logical_expr stack machine, accumulating across nested sub-expressions via PlannerContext, and return a planning error when it exceeds recursion_limit * 10.

Are these changes tested?

Yes. New unit tests cover: chains within the limit succeed, over-deep chains return a graceful error, and depth accumulates across nesting. Existing deep-chain tests still pass.

Are there any user-facing changes?

Pathologically deep expressions now return a planning error instead of crashing. No API changes.