CLN: Use signed integers in khash maps for signed integer keys

- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`

The goal of this PR is to make this comment obsolete: https://github.com/pandas-dev/pandas/blob/1fc5efd76ea1f85979fa2364a292d85482e338aa/pandas/_libs/src/klib/khash.h#L619-L624

see also [this discussion]( https://github.com/pandas-dev/pandas/pull/37920#discussion_r527191378) for even more details.

The issue is:

- the current way (inherited from khash-original) is too clever (and suprising)
- it is wrong as the (unsigned) keys are converted back to signed values (which is implementation defined behavior) for example here: https://github.com/pandas-dev/pandas/blob/1fc5efd76ea1f85979fa2364a292d85482e338aa/pandas/_libs/hashtable_func_helper.pxi.in#L110

Using signed integer, one must take into account that hash-function with signed integers might have undefined/implementation defined behavior, thus we cast signed integers to unsigned counterpart in the (64bit-) hash function now.
this looks fine. I assume that nothing in the current impl breaks because of this (e.g. converting int -> uint is safe as far as our tests go). any perf implications? @jreback I expect no perf changes and ran asv only for a subset of tests ( `-b hash_functions -b ^algorithms -b ^indexing`) and there were no changes (albeit `hash_functions.NumericSeriesIndexing` seems to be somewhat flacky on my machine - but I have observed this behavior in other PRs as well). thanks @realead 