temporal cast overflows/panics

[Jefffrey]

Describe the bug

some of the cast paths (for temporal types like time/date/timestamp) don't protect against overflows/underflows/panics properly.

To Reproduce

// arrow-cast/src/cast/mod.rs
    #[test]
    fn test123() {
        let a = Date64Array::from(vec![i64::MAX]);
        let b = cast(&a, &DataType::Date32).unwrap();
        let b = b.as_primitive::<Date32Type>();
        dbg!(b.value(0)); // outputs -622191233

        let a = Time32SecondArray::from(vec![i32::MAX]);
        let _ = cast(&a, &DataType::Time32(TimeUnit::Millisecond));
    }

output of test

running 1 test
[arrow-cast/src/cast/mod.rs:13904:9] b.value(0) = -622191233

thread 'cast::tests::test123' (6354242) panicked at arrow-cast/src/cast/mod.rs:1722:56:
attempt to multiply with overflow
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test cast::tests::test123 ... FAILED

failures:

failures:
    cast::tests::test123

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 352 filtered out; finished in 0.00s

error: test failed, to rerun pass `-p arrow-cast --lib`

Expected behavior

for the date64 -> date32, we underflow to a negative value. we should respect the cast safety option (either null it or explicitly error)

for time32 second -> time32 milli it panics. same as above, we should respect the cast safety option.

Additional context

inspired by #9824

[Jefffrey]

this seems like a good opportunity to point an LLM at our cast code to see what other combinations can cause such issues; i only manually examined to find 2 examples but im sure theres more i didnt list here. i would prefer keeping this issue open until we're sure for temporal casts that we dont have any more over/underflow or panic behaviour