feat(python): infer ISO8601 datetimes

[MarcoGorelli]

closes #6356

This contains the same formats as on master, but with plenty of added ones. No format has been removed (though I am suggesting to remove a couple in #6378)

Where I ran the benchmarks: https://www.kaggle.com/code/marcogorelli/polars-timing?scriptVersionId=117053341

[will fill out below when it completes]

parsing a single element:

from IPython import get_ipython
ipython = get_ipython()
import polars as pl

ipython.run_line_magic("timeit", "pl.Series(['1900/01/01 12:00:00 AM']).str.strptime(pl.Datetime)")

On this branch (with make build-release):

192 µs ± 7.01 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
192 µs ± 10.7 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
189 µs ± 8.4 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

On master (with make build-release, after having deleted all non-tracked files):

161 µs ± 15.3 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
160 µs ± 7.67 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
173 µs ± 7.92 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

parsing multiple elements (with consistent format):

from IPython import get_ipython
from datetime import datetime
ipython = get_ipython()
import polars as pl

date_range = pl.date_range(low=datetime(1300, 1, 1), high=datetime(2300, 1, 1), interval="12h").dt.strftime('%Y/%m/%d %I:%M:%S %p')

ipython.run_line_magic("timeit", "date_range.str.strptime(pl.Datetime)")

On this branch (with make build-release):

295 ms ± 808 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
296 ms ± 820 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
302 ms ± 7.28 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

On master (with make build-release, after having deleted non-tracked files):

295 ms ± 985 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
301 ms ± 10.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
295 ms ± 1.3 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

[ritchie46]

I think the slowdown might be in the csv parsing, but I think it is worth it for now. We can likely speed that up, by caching formats in a lru manner. Let me know when you think it is good to go.

[MarcoGorelli]

Sure, ready for review, thanks!

IIUC: for parsing a single element, this is a bit slower, because it needs to try all the YMD formats until it finds one that works in

polars/polars/polars-time/src/chunkedarray/utf8/infer.rs

Lines 206 to 209 in 8eced68

	} else if patterns::DATETIME_Y_M_D.iter().any(|fmt| {
	NaiveDateTime::parse_from_str(val, fmt).is_ok()
	|| NaiveDate::parse_from_str(val, fmt).is_ok()
	}) {

but for parsing multiple elements with a consistent format, then it will reuse the latest guess in latest and so will be fast

polars/polars/polars-time/src/chunkedarray/utf8/infer.rs

Lines 64 to 71 in 8eced68

	Pattern::DateYMD => Ok(DatetimeInfer {
	patterns: patterns::DATE_Y_M_D,
	latest: patterns::DATE_Y_M_D[0],
	transform: transform_date,
	transform_bytes: transform_date_bytes,
	fmt_len: 0,
	logical_type: DataType::Date,
	}),

and that's why the first benchmark above shows a slight slowdown, whereas for the second one (with multiple consistently-formatted elements) there is no noticeable difference

[ritchie46]

That's indeed the tradeoff. Seems like a reasonable concession for the added ergonomics.