fix: Avoid integer overflow in substr()

[neilconway]

Rationale for this change

Evaluating SELECT SUBSTR('', 2, 9223372036854775807); yields (in a debug build):

thread 'main' (41414592) panicked at datafusion/functions/src/string/split_part.rs:236:47:
attempt to negate with overflow
stack backtrace:
   0: __rustc::rust_begin_unwind
             at /rustc/ded5c06cf21d2b93bffd5d884aa6e96934ee4234/library/std/src/panicking.rs:698:5
   1: core::panicking::panic_fmt
             at /rustc/ded5c06cf21d2b93bffd5d884aa6e96934ee4234/library/core/src/panicking.rs:80:14
   2: core::panicking::panic_const::panic_const_neg_overflow
             at /rustc/ded5c06cf21d2b93bffd5d884aa6e96934ee4234/library/core/src/panicking.rs:180:17
   3: datafusion_functions::string::split_part::split_part_impl::{{closure}}
             at ./datafusion/functions/src/string/split_part.rs:236:47
   4: core::iter::traits::iterator::Iterator::try_for_each::call::{{closure}}
             at /Users/neilconway/.rustup/toolchains/1.92.0-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/iter/traits/iterator.rs:2485:26
[...]

Found via fuzzing.

Are these changes tested?

Yes, added a unit test.

[Jefffrey]

Is it better to saturate at i64::MAX or just error out?

[alamb]

Thanks @neilconway and @Jefffrey

[alamb]

won't using floating point arithmetic be slower? Perhaps we could simply return an error if we got an overflow? Or use saturating_add ?