fix(rust,python): address multiple issues caused by implicit casting of is_in values to the column dtype being searched

[alexander-beedie]

Closes #11394.

• The linked issue shows that we were casting is_in values to string if the target series was Utf8:

  from datetime import date
  import polars as pl
  
  df = pl.DataFrame({
      "a": ["1","2"],
      "b": [3,4],
  })
  df.filter( pl.col("a").is_in([1,2]) )  # << filtering string by int64 🚫
  # ┌─────┬─────┐
  # │ a   ┆ b   │
  # │ --- ┆ --- │
  # │ str ┆ i64 │
  # ╞═════╪═════╡
  # │ 1   ┆ 3   │
  # │ 2   ┆ 4   │
  # └─────┴─────┘

• This led down a surprisingly deep rabbit-hole, as various other incompatible dtype pairs were being allowed via implicit cast, leading to incorrect or weird/misleading results - for example, the following filters silently cast and drop all results:

  df = pl.DataFrame({
      "a": ["1","2"],
      "b": [3,4],
  })
  df.filter( pl.col("a").is_in([date.today()]) )  # << filtering string by date 🚫
  # ┌─────┬─────┐
  # │ a   ┆ b   │
  # │ --- ┆ --- │
  # │ str ┆ i64 │
  # ╞═════╪═════╡
  # └─────┴─────┘
  
  df.filter( pl.col("b").is_in([date.today()]) )  # << filtering int64 by date 🚫
  # ┌─────┬─────┐
  # │ a   ┆ b   │
  # │ --- ┆ --- │
  # │ str ┆ i64 │
  # ╞═════╪═════╡
  # └─────┴─────┘

  I've resolved this by raising InvalidOperationError where the dtype of the is_in values is not a reasonable match for the dtype of the target Series. We should fail with a clear error here; if the user wants to cast, they can do so explicitly without any trouble.

  In the cases above this means we now raise the following exceptions:

  InvalidOperationError: 
    `is_in` cannot check for Int64 values in Utf8 data
    `is_in` cannot check for Date values in Int64 data
  

• Also spotted that we could return false positives on datetime/duration matches by allowing is_in values with a more granular time_unit than the target Series (as we don't cast to supertype); this could also lead to incorrect filtering:

  # data has millisecond precision
  df = pl.DataFrame({
      "d": [datetime(2022,10,20,10,30,45,123000)],
  }, schema_overrides={"d": pl.Datetime("ms")})
  
  # filter value has microsecond precision and should NOT match!
  df.filter( 
      pl.col("d").is_in([datetime(2022,10,20,10,30,45,123456)])  # (ms > μs) 🚫
  )
  
  # but... :(
  # ┌─────────────────────────┐
  # │ d                       │
  # │ ---                     │
  # │ datetime[ms]            │
  # ╞═════════════════════════╡
  # │ 2022-10-20 10:30:45.123 │
  # └─────────────────────────┘

  Solved this by validating that the relative time_unit values cannot result in silent truncation/rounding. The above example now raises the following:

  InvalidOperationError: 
    `is_in` cannot check for Microseconds precision values in Milliseconds Datetime data
  

(Note that we still allow all of the obvious/expected casts between basic int/float numeric dtypes, etc - only clearly mismatched dtypes -as above- will now raise an exception).

[ritchie46]

Nice one thanks!