Vendored klib quadatric probing
State: closed

Changes vendored from https://github.com/attractivechaos/klib/commit/0afbad198cfcf6db0aa03356f1ac69d9137b4c53

Hashing benchmarks:

```sh
asv continuous -f 1.1 -E virtualenv upstream/main HEAD -b ^indexing

       before           after         ratio
     [aa051b8f]       [f60d0c3b]
     <main>           <quadratic-probing>
-        51.2±3μs       46.5±0.4μs     0.91  hash_functions.NumericSeriesIndexingShuffled.time_loc_slice(<class 'pandas.core.indexes.numeric.Float64Index'>, 100000)
-     1.51±0.01ms      1.37±0.03ms     0.91  hash_functions.Unique.time_unique_with_duplicates('Int64')
-      3.34±0.1ms      3.01±0.07ms     0.90  hash_functions.Unique.time_unique_with_duplicates('Float64')
-     2.98±0.01ms      2.66±0.05ms     0.89  hash_functions.NumericSeriesIndexing.time_loc_slice(<class 'pandas.core.indexes.numeric.UInt64Index'>, 1000000)
-      16.2±0.7ms       13.9±0.9ms     0.86  hash_functions.UniqueAndFactorizeArange.time_factorize(13)
-      9.56±0.4ms       7.84±0.3ms     0.82  hash_functions.UniqueAndFactorizeArange.time_unique(14)
-      9.60±0.5ms       7.84±0.3ms     0.82  hash_functions.UniqueAndFactorizeArange.time_unique(9)
-      9.63±0.5ms       7.84±0.3ms     0.81  hash_functions.UniqueAndFactorizeArange.time_unique(13)
-      9.61±0.4ms       7.80±0.4ms     0.81  hash_functions.UniqueAndFactorizeArange.time_unique(6)
-      9.57±0.5ms       7.76±0.3ms     0.81  hash_functions.UniqueAndFactorizeArange.time_unique(12)
-      9.59±0.4ms       7.73±0.4ms     0.81  hash_functions.UniqueAndFactorizeArange.time_unique(11)
-      9.58±0.5ms       7.72±0.3ms     0.81  hash_functions.UniqueAndFactorizeArange.time_unique(10)
-      9.62±0.5ms       7.71±0.4ms     0.80  hash_functions.UniqueAndFactorizeArange.time_unique(4)
-      9.62±0.5ms       7.71±0.4ms     0.80  hash_functions.UniqueAndFactorizeArange.time_unique(7)
-      9.89±0.5ms       7.76±0.4ms     0.78  hash_functions.UniqueAndFactorizeArange.time_unique(15)
-      9.80±0.5ms       7.68±0.4ms     0.78  hash_functions.UniqueAndFactorizeArange.time_unique(5)
-      9.85±0.5ms       7.71±0.3ms     0.78  hash_functions.UniqueAndFactorizeArange.time_unique(8)
-         375±1ms          291±6ms     0.78  hash_functions.NumericSeriesIndexingShuffled.time_loc_slice(<class 'pandas.core.indexes.numeric.Float64Index'>, 5000000)
-        390±10ms          298±9ms     0.77  hash_functions.NumericSeriesIndexing.time_loc_slice(<class 'pandas.core.indexes.numeric.Float64Index'>, 5000000)
-       115±0.4ms          131±5μs     0.00  hash_functions.NumericSeriesIndexing.time_loc_slice(<class 'pandas.core.indexes.numeric.Int64Index'>, 5000000)

SOME BENCHMARKS HAVE CHANGED SIGNIFICANTLY.
PERFORMANCE INCREASED.
```

```sh
asv continuous -f 1.1 -E virtualenv upstream/main HEAD -b algorithms.Factorize

       before           after         ratio
     [aa051b8f]       [f60d0c3b]
     <main>           <quadratic-probing>
-        319±10μs          271±4μs     0.85  algorithms.Factorize.time_factorize(True, False, 'boolean')
-     1.87±0.05ms      1.54±0.04ms     0.82  algorithms.Factorize.time_factorize(False, True, 'boolean')
-         423±2μs          346±4μs     0.82  algorithms.Factorize.time_factorize(True, True, 'boolean')
-     1.49±0.06ms      1.19±0.03ms     0.80  algorithms.Factorize.time_factorize(False, False, 'boolean')

SOME BENCHMARKS HAVE CHANGED SIGNIFICANTLY.
PERFORMANCE INCREASED.
```

Labels:
name: Performance
description: Memory or execution speed performance

Comments:
not having looked at the code yet: neat!
Don't think it is dependent on anything prior. Things are a bit muddled because we vendored klib and edited directly, but AFAICT upstream works as a standalone patch
Thanks @WillAyd 
@WillAyd - I'm seeing a performance regression with `isin` due to this PR, is that expected?

https://asv-runner.github.io/asv-collection/pandas/#algos.isin.IsInForObjects.time_isin?p-series_type='nans'&p-vals_type='long'&commits=2317bf08
Thanks for the heads up. Will take a look this week
After some review it looks like the slowdown is pretty signficant for the case where we have a Series full of nan. I'm guessing there are a lot of collisions going on that the quadratic probing may not handle as well as the previous double hashing. 

I'll push up a PR to revert this. Will require more research. Thanks @rhshadrach for the find