PERF: Introducing hash tables for complex64 and complex128
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

Next step for #33287

The complex case is somewhat less straight forward, because Cython [defines](https://github.com/cython/cython/blob/master/Cython/Includes/numpy/__init__.pxd#L755) `complex128`/`complex64` as:

```
ctypedef float complex  complex64_t
ctypedef double complex complex128_t
```

where `double complex` actually means a Cython-datatype defined here https://github.com/cython/cython/blob/master/Cython/Utility/Complex.c#L56

Thus a conversion between numpy's complex and Cython's complex must happens somewhere.




FYI @jbrockmendel 

Some polishing is still needed and probably additional testing, but this is how it could look like.

Maybe you know a better solution for the whole numpy's <->cython's complex-business.

There are also some details, which maybe need some tinkering:
   * Right now,  `nan+1j` and `1+nan*j` are considered not-a-number. However, they aren't considered equivalent. Not sure that doesn't make any problems.
   * `inf +nan*j` is considered not-a-number, maybe it makes more sense to see it as infinity and not not-a-number

 Failures seem to be unrelated to my changes... > Failures seem to be unrelated to my changes...

Yes.  The npdev failure I think should be fixed by #38209 and the other one just annoyingly happens sometimes because hypothesis is slow.  Don't worry about either. can you merge master and will look again ok looks good. this complex 64/128 are available on all platforms? > ok looks good. this complex 64/128 are available on all platforms?

@jreback It should work on platforms which have 64bit- and 32bit floating numbers. As we don't really use complex arithmetic it is not important whether C-compiler supports complex-numbers or not. thanks @realead 