perf: simplify negated predicates to improve row groups skipping

[taki-mekhalfa]

This simplifies usual boolean predicates to allow for more row groups skippings when reading parquets or pruning hive partitions.

- not(a = b) => a != b
- not(a != b) => a == b
- not(a < b) => a >= b (likewise for a <= b)
- not(a > b) => a <= b (likewise for a >= b)
- not(a and b) => not(a) or not(b)
- not(a or b) => not(a) and not(b)
- not(col(x) IS BETWEEN [a, b]) => col(x) < a or col(x) > b

Here are some examples:

>>> pl.scan_parquet('examples/datasets/foods1.parquet').filter(~(pl.col('calories')<300)).collect()
parquet file can be skipped, the statistics were sufficient to apply the predicate.
shape: (0, 4)
┌──────────┬──────────┬────────┬──────────┐
│ category ┆ calories ┆ fats_g ┆ sugars_g │
│ ---      ┆ ---      ┆ ---    ┆ ---      │
│ str      ┆ i64      ┆ f64    ┆ i64      │
╞══════════╪══════════╪════════╪══════════╡
└──────────┴──────────┴────────┴──────────┘

>>> pl.scan_parquet('examples/datasets/foods1.parquet').filter(~(pl.col('calories')>=15)).collect()
parquet file can be skipped, the statistics were sufficient to apply the predicate.
shape: (0, 4)
┌──────────┬──────────┬────────┬──────────┐
│ category ┆ calories ┆ fats_g ┆ sugars_g │
│ ---      ┆ ---      ┆ ---    ┆ ---      │
│ str      ┆ i64      ┆ f64    ┆ i64      │
╞══════════╪══════════╪════════╪══════════╡
└──────────┴──────────┴────────┴──────────┘

>>> pl.scan_parquet('examples/datasets/foods1.parquet').filter(~(pl.col('calories').gt(200) | pl.col('sugars_g').le(30))).collect()
parquet file must be read, statistics not sufficient for predicate.
parquet file can be skipped, the statistics were sufficient to apply the predicate.
shape: (0, 4)
┌──────────┬──────────┬────────┬──────────┐
│ category ┆ calories ┆ fats_g ┆ sugars_g │
│ ---      ┆ ---      ┆ ---    ┆ ---      │
│ str      ┆ i64      ┆ f64    ┆ i64      │
╞══════════╪══════════╪════════╪══════════╡
└──────────┴──────────┴────────┴──────────┘

[taki-mekhalfa]

I did this because I am not sure if otherwise it would hurt performance if we duplicate a more complex input into two predicates

[ritchie46]

Thank you @taki-mekhalfa