Minor: Fix clippy by switching to timestamp_nanos_opt instead of (deprecated) timestamp_nanos

[alamb]

Which issue does this PR close?

Closes #.

Rationale for this change

https://crates.io/crates/chrono/0.4.31 was released recently and it appears to deprecated timestamp_nanos. This results in local clippy failures for me

error: use of deprecated method `chrono::DateTime::<Tz>::timestamp_nanos`: use `timestamp_nanos_opt()` instead
   --> datafusion/physical-expr/src/datetime_expressions.rs:171:30
    |
171 |     let now_ts = Some(now_ts.timestamp_nanos());
    |                              ^^^^^^^^^^^^^^^
    |
    = note: `-D deprecated` implied by `-D warnings`

What changes are included in this PR?

Use the non-deprecated API

Are these changes tested?

by existing tests

Are there any user-facing changes?

[alamb]

I think timestamp_nanos() was deprecated as it can panic internally -- timestamp_nanos_opt can not panic (and returns None if the value can not be represented)

[tustvold]

Is this correct, it will convert a panic into 0?

[alamb]

I don't expect that the metrics would produce timestamps that can't be converted to nanoseconds so it is somehwhat a theoretical difference.

I could see the argument being made to preserve the existing behavior (panic if somehow the values can't be represented as a timestamp) but I also think returning 0 rather than panic'ing in that case (what this PR does) is also reasonable

[tustvold]

Just one niggle

[alamb]

in order to get CI back healthy, I am going to merge this PR in. If anyone has other opinions about the 0 vs panic case that @tustvold points out on #7572 (comment) let me know and I can change it

[alamb]

I think this needs a follow on to pin chrono: #7575