Displaying a `Date64` scalar of `i64::MIN` panics

### Describe the bug

Formatting a `ScalarValue::Date64` whose value is `i64::MIN` panics. The `Display` impl unwraps `chrono::Duration::try_milliseconds(v)`, which returns `None` for `i64::MIN` because that value is outside the range `chrono::Duration` can represent (`datafusion/common/src/scalar/mod.rs`, `Date64` arm of `impl fmt::Display for ScalarValue`).

Any code path that prints such a literal hits it, e.g. plan display.

### To Reproduce

```sql
EXPLAIN SELECT arrow_cast(-9223372036854775808, 'Date64');
```

```text
thread 'main' panicked at datafusion/common/src/scalar/mod.rs:5661:82:
called `Option::unwrap()` on a `None` value
```

Also reachable during execution, e.g. a RANGE window frame over a `Date64` column that contains `i64::MIN`:

```sql
SELECT count(*) OVER (ORDER BY x RANGE BETWEEN 1 PRECEDING AND 1 FOLLOWING)
FROM (VALUES (arrow_cast(9223372036854775807, 'Date64')), (arrow_cast(-9223372036854775808, 'Date64'))) t(x);
```

### Expected behavior

No panic. The neighbouring branch already maps an unrepresentable epoch offset to an empty string (added for apache/arrow-rs#7728); `i64::MIN` should behave the same way.

### Additional context

Found while running a corpus of extreme-value literals against a debug build of `datafusion-cli`.

Start in datafusion/common/src/scalar/mod.rs at the Date64 arm of impl fmt::Display for ScalarValue, then reproduce the failure with EXPLAIN SELECT arrow_cast(-9223372036854775808, 'Date64'). Check the neighbouring handling for unrepresentable epoch offsets. Done means displaying this i64::MIN value no longer panics and follows the existing empty-string behavior.

Written by the indexing model from the issue text.