feat(rust, python): let "ambiguous" take "null" value

[MarcoGorelli]

Suggested by @stinodego here, but also:

• 'null' may need adding anyway for dealing with non-existent datetimes gracefully (Enable handling non-existent times in expr.dt.replace_time_zone #11579 (comment))
• this matches ambiguous='NaT' from pandas

Demo:

In [7]: df = pl.DataFrame({
   ...:     'ts': pl.datetime_range(datetime(2020, 10, 25), datetime(2020, 10, 25, 6), '1h', eager=True),
   ...:     })

In [8]: df
Out[8]: 
shape: (7, 1)
┌─────────────────────┐
│ ts                  │
│ ---                 │
│ datetime[μs]        │
╞═════════════════════╡
│ 2020-10-25 00:00:00 │
│ 2020-10-25 01:00:00 │
│ 2020-10-25 02:00:00 │
│ 2020-10-25 03:00:00 │
│ 2020-10-25 04:00:00 │
│ 2020-10-25 05:00:00 │
│ 2020-10-25 06:00:00 │
└─────────────────────┘

In [9]: df.with_columns(
   ...:     ts_replaced = pl.col('ts').dt.replace_time_zone('Europe/London', ambiguous='null')
   ...: )
Out[9]: 
shape: (7, 2)
┌─────────────────────┬─────────────────────────────┐
│ ts                  ┆ ts_replaced                 │
│ ---                 ┆ ---                         │
│ datetime[μs]        ┆ datetime[μs, Europe/London] │
╞═════════════════════╪═════════════════════════════╡
│ 2020-10-25 00:00:00 ┆ 2020-10-25 00:00:00 BST     │
│ 2020-10-25 01:00:00 ┆ null                        │
│ 2020-10-25 02:00:00 ┆ 2020-10-25 02:00:00 GMT     │
│ 2020-10-25 03:00:00 ┆ 2020-10-25 03:00:00 GMT     │
│ 2020-10-25 04:00:00 ┆ 2020-10-25 04:00:00 GMT     │
│ 2020-10-25 05:00:00 ┆ 2020-10-25 05:00:00 GMT     │
│ 2020-10-25 06:00:00 ┆ 2020-10-25 06:00:00 GMT     │
└─────────────────────┴─────────────────────────────┘

[MarcoGorelli]

hmm I'm seeing a slight perf regression here. small, but looks real?

https://www.kaggle.com/code/marcogorelli/polars-timing?scriptVersionId=145820321

here:

• min: 34.58047724000062
• max: 34.82023904700054
• avg: 34.7417660610001 +/- 0.02811013567654737

main:

• min: 33.56916854799965
• max: 34.206052164999164
• avg: 33.85647739228547 +/- 0.08204153267322174

---

I don't know, is there a way to do this that might preserve performance?

[MarcoGorelli]

closing as I don't think extra complexity is warranted here, can revisit if there's demand