fix: validate time zone config before applying changes

[Probablism]

Which issue does this PR close?

• Part of The config values aren't checked #17498

Rationale for this change

datafusion.execution.time_zone accepted a raw string value, so invalid
timezones could be stored in the session config and fail later when timestamp
operations tried to parse them.

This changes the config value to store a parsed timezone, so invalid timezone
values are rejected when the setting is applied and the previous valid value
remains active.

What changes are included in this PR?

• Add a ConfigTimeZone wrapper around Arrow's parsed timezone type.
• Change ExecutionOptions::time_zone from Option<String> to
  Option<ConfigTimeZone>.
• Update datetime, SQL, Spark, UDF, and FFI call sites to use the typed config
  value and only convert back to a string where Arrow metadata/display requires
  it.
• Add regression coverage for valid values, invalid values, nested config keys,
  SQL SET behavior, and UDF/FFI config propagation.

Are these changes tested?

Yes.

• cargo fmt --all
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test -p datafusion-common test_execution_time_zone_validation
• cargo test -p datafusion --test user_defined_integration test_config_options_work_for_scalar_func
• cargo test -p datafusion-ffi --features integration-tests --test ffi_udf test_config_on_scalar_udf
• cargo test -p datafusion-functions timezone
• cargo test --profile=ci --test sqllogictests -- set_variable
• cargo check -p datafusion-common -p datafusion-sql -p datafusion-functions -p datafusion-spark -p datafusion-ffi -p datafusion --tests

Are there any user-facing changes?

Yes. Invalid SET TIME ZONE values now fail immediately instead of being
accepted and causing later timestamp operations to fail.

[Jefffrey]

would it be possible to enforce it more strictly by changing the type of the config to Tz? or is this infeasible for other reasons

datafusion/datafusion/common/src/config.rs

Lines 770 to 773 in ea2ffdb

	/// The default time zone
	///
	/// Some functions, e.g. `now` return timestamps in this time zone
	pub time_zone: Option<String>, default = None

[Probablism]

Good point. I had kept this as a string initially to avoid changing the config type, but I agree the typed version is better here.

I updated it to store a parsed timezone via ConfigTimeZone. It wraps Arrow's Tz because the config structs need PartialEq, and Tz doesn't provide that directly.

[Jefffrey]

for the most part this looks good, just wondering if there'll be downstream impacts to warrant marking this a breaking API change 🤔

[Jefffrey]

this change is interesting; were the tests just flawed previously and AEST was never a valid timezone (but we never tried parsing it)?

[Jefffrey]

hm i wonder if this is significant

i wonder if we have some precedent from other engines (duckdb, spark) if they handle in a similar way or not