fix: Support RANGE window frames over Time32/Time64 ORDER BY keys

[waterWang]

Which issue does this PR close?

• Closes Window functions fail when ORDER BY uses a TIME column #24514.

Rationale for this change

Window functions whose leading ORDER BY key is Time32 or Time64 fail during type coercion, even when no frame clause is specified.

ORDER BY without a frame defaults to RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and extract_window_frame_target_type had no arm for the time types. Time32(Second), Time32(Millisecond), Time64(Microsecond), Time64(Nanosecond) and dictionary-wrapped time values are all affected. Those bounds only need to compare order key values, which time values support just as Utf8 does.

A finite offset like INTERVAL '1' HOUR PRECEDING is different: time/interval arithmetic wraps around the 24-hour clock, so it should produce a planning error rather than an internal error.

What changes are included in this PR?

• extract_window_frame_target_type in datafusion/optimizer/src/analyzer/type_coercion.rs: added Time32 and Time64 to the match arm that returns the order key type as-is (free range)
• datafusion/sqllogictest/test_files/window.slt: added tests for free range frames over Time64(Microsecond), Time32(Second), Time32(Millisecond), dictionary-wrapped time, and RANK(); planning error tests for INTERVAL PRECEDING/FOLLOWING offsets

Are these changes tested?

Yes, by the new sqllogictest cases in window.slt.

Are there any user-facing changes?

• Free range frames (default RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) over Time32/Time64 ORDER BY keys now plan and execute successfully instead of failing with an internal error.
• RANGE with an INTERVAL PRECEDING/FOLLOWING offset over a time order key is now rejected with a planning error instead of an internal error.

[nuno-faria]

Duplicate of #24515, closing in favor of that.