fix: prevent next_day panic on far-future start dates - #24194

## Which issue does this PR close?

- Closes apache#23891.

## Rationale for this change

`datafusion-spark`'s `next_day` computed its result by adding the day
offset to a `chrono::NaiveDate`:

```rust
Some(Date32Type::from_naive_date(
    date + Duration::days((7 - date.weekday().days_since(day_of_week)) as i64),
))
```

When the next occurrence of the requested weekday lands past
`chrono::NaiveDate::MAX` (epoch day `95026236`) — which happens for
start dates in the last week of the representable `Date32` range — the
`NaiveDate + TimeDelta` add **panics** with `NaiveDate + TimeDelta
overflowed`. (The linked issue reports NULL; the scalar path in fact
panics.)

Spark's `DateTimeUtils.getNextDateForDayOfWeek` is pure integer
arithmetic on the epoch day and always produces a value:

```scala
def getNextDateForDayOfWeek(startDay: Int, dayOfWeek: Int): Int = {
  startDay + 1 + ((dayOfWeek - 1 - startDay) % 7 + 7) % 7
}
```

## What changes are included in this PR?

- Compute the result on the epoch day directly (`days + delta`, via
`checked_add`) instead of building a `NaiveDate` for the result, so a
next occurrence past `NaiveDate::MAX` returns a value instead of
panicking. The weekday/offset logic is unchanged, so results for all
in-range dates are identical.

Scope note: a *start* day beyond `NaiveDate::MAX` (`> 95026236`) still
returns NULL, because the weekday is derived via `NaiveDate`. Extending
full `Int`-range parity (computing the weekday arithmetically too) is a
larger change left as a follow-up; this PR fixes the panic, which is the
concrete reported harm.

## Are these changes tested?

Yes.

- Unit test `next_day_handles_far_future_start_dates` covering the two
cases from the issue (`95026236`/`Mon`, `95026230`/`Tue`), each of which
panicked before this change.
- SLT coverage in `spark/datetime/next_day.slt` asserting the same two
cases (casting the `Date32` result to `Int32`, since these dates are
past the printable range).

## Are there any user-facing changes?

`next_day` no longer panics for far-future start dates; it returns the
correct epoch day. No API changes.

Spark's NextDay has taken failOnError = SQLConf.get.ansiEnabled since at least
3.5, raising on an unparseable day-of-week name and returning NULL otherwise.
datafusion-spark ignored the flag and always returned NULL, with TODO comments
acknowledging the gap. It now honors datafusion.execution.enable_ansi_mode,
preserving Spark's per-row null intolerance: a NULL start date short circuits
to NULL before the name is validated.

One version-independent bug is fixed alongside it:

- SELECT next_day(<date literal>, <string column>) hit an unreachable
  catch-all and raised a hard error. The match over ColumnarValue shapes is
  now exhaustive.

The day-of-week parsing and the date arithmetic are split into
parse_day_of_week and next_date_for_day_of_week so the ANSI branch has a single
place to decide between raising and appending NULL.

This branch originally also fixed a panic for epoch days in 95026230..=95026236
by switching to checked_add_signed, which avoided the panic but returned NULL.
That panic has since been fixed on main by apache#24194, which computes the result on
the epoch day and returns the value Spark's Int arithmetic produces. This rebase
keeps main's behavior and drops the weaker fix; the tests and slt cases that
asserted NULL past chrono::NaiveDate::MAX now assert the epoch day instead.

The only version-specific change is the error message text, which now matches
Spark 4.2.0's ILLEGAL_DAY_OF_WEEK template rather than 3.5.8's older
IllegalArgumentException string. The remaining cross-version divergence, the
ANSI default flip and error class change, is not addressed here and is tracked
by https://github.com/apache/datafusion/issues/23890