[VL] Fix Arrow vendored datetime build failure on macOS C++20 libc++

[jackylee-ch]

What changes are proposed in this pull request?

Building Arrow CPP on macOS with -std=c++20 and Apple Clang's libc++
fails at the first translation unit that includes
vendored/datetime/tz_private.h:

cpp/src/arrow/vendored/datetime/tz.cpp:
  error: use of overloaded operator '<<' is ambiguous
  (with operand types 'std::ostream' and 'const date::sys_seconds')

Arrow 15.0.0 ships a vendored copy of Howard Hinnant's date library.
On macOS -std=c++20, libc++'s std::chrono exposes its own
operator<< for sys_time and related clock types that collides
with date::operator<< pulled in via using namespace date; /
using date::operator<<; inside vendored/datetime/tz.cpp and
tz_private.h.

Linux libstdc++ does not expose the conflicting chrono::operator<<,
so the build is unaffected there.

This PR adds ep/build-velox/src/fix_vendored_datetime_operator.patch
that replaces the ADL-driven os << timepoint call sites with an
explicit qualified call date::operator<<(os, timepoint) so the
vendored overload is selected unambiguously regardless of what
std::chrono provides. The patch is applied from
dev/build-arrow.sh::prepare_arrow_build after the existing Arrow
patches (modify_arrow.patch, modify_arrow_dataset_scan_option.patch,
cmake-compatibility.patch, support_ibm_power.patch).

Two callsites are touched, both inside Arrow's vendored date code:

File	Function	Change
cpp/src/arrow/vendored/datetime/tz.cpp:2734	operator<<(std::ostream&, const leap_second&)	drop using namespace date;, call date::operator<<(os, x.date_)
cpp/src/arrow/vendored/datetime/tz_private.h:291	operator<<(std::ostream&, const transition&)	drop using date::operator<<;, call date::operator<<(os, t.timepoint)

The patch is platform-agnostic: explicit qualification works on any
toolchain. Linux builds (which currently succeed) are unaffected
because the rewritten call resolves to the same overload they
previously selected via ADL.

Relationship to #11869

This is a different and lower-layer problem from #11869, even though
both are macOS-only and timezone-adjacent:

	#11869 (merged)	this PR
Failure time	Runtime, when a Spark query runs with spark.sql.session.timeZone=GMT	Compile time, during the Arrow CPP build itself
Symptom	session 'session_timezone' set with invalid value 'GMT'	error: use of overloaded operator '<<' is ambiguous
Root cause	macOS Folly/Velox tzdb does not accept GMT as a valid IANA name	C++20 libc++ added chrono::operator<< overloads that collide with the vendored date::operator<< via ADL
Layer	Gluten / Velox runtime config	Arrow vendored Howard Hinnant date library (compile-time << ADL)
Files touched	6 files in backends-velox/, cpp/core/, cpp/velox/	dev/build-arrow.sh + new ep/build-velox/src/fix_vendored_datetime_operator.patch (patches Arrow's vendored datetime)
Trigger	Specific user config (spark.sql.session.timeZone=GMT)	Any -std=c++20 + libc++ macOS build, regardless of config

Without the change in this PR, Arrow CPP fails to compile, so
libarrow.a / libvelox.dylib / libgluten.dylib are never produced
and #11869's runtime fix has no chance of being exercised on macOS
libc++ in the first place. They are complementary: #11869 fixes the
runtime tz config flow; this PR unblocks the build that hosts that
runtime.

How was this patch tested?

• macOS 14 arm64 with Apple Clang 17 (-std=c++20): Arrow CPP build
  reaches successful link of libarrow.a, libarrow_cdata_jni.dylib,
  libarrow_dataset_jni.dylib. Before the patch, the build aborted at
  the first TU including tz_private.h with the ambiguity error
  shown above.
• macOS Spark 3.5 + Velox backend Java JNI canary suites
  (VeloxBloomFilterTest, ColumnarBatchTest, VeloxListenerApiTest,
  OnHeapFileSystemTest, ArrowColumnVectorTest) all pass on the
  resulting build.
• Linux x86_64 Ubuntu 22.04 build green; the rewritten call sites
  resolve to the same date::operator<< overload as before. Local
  Ubuntu build verified clean.

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

co-auth: Claude (Sonnet/Opus) via Claude Code 1.x