[SPARK-59325][SQL] Add an optional maximum nesting depth for variant values

[HyukjinKwon]

What changes were proposed in this pull request?

Add an opt-in spark.sql.variant.maxNestingDepth (internal, default -1 = unlimited = unchanged).
When set to a positive value, rendering a variant value whose nesting exceeds it fails instead of
recursing without bound. The limit is threaded as a parameter into the recursive variant read
paths so common/variant does not need SQLConf access:

• Variant.toJson / toJsonImpl and VariantVal.toJson gain overloads carrying the limit; the
  existing signatures delegate with -1 (unchanged).
• The SQL cast/variant_get-to-string path, the Parquet variant shredding read, and
  to_json obtain the limit once (per expression / per task), not per row.

Why are the changes needed?

Variant.toJsonImpl recursed per nested element with no bound, so a deeply nested variant could
exhaust the stack when rendered. The existing size limit does not prevent this (a small-per-level
variant can nest very deeply within the size cap). This adds an optional bound.

Does this PR introduce any user-facing change?

No by default. When spark.sql.variant.maxNestingDepth is set to a positive value, variant values
nested more deeply than the limit raise an error when rendered.

How was this patch tested?

New VariantExpressionSuite case: a deeply nested variant renders fully when the limit is unset or
generous and is rejected when the limit is smaller than its depth.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Isaac

This pull request and its description were written by Isaac.

Co-authored-by: Isaac no-reply@databricks.com