The test assumed incorrectly that Python’s sys.maxsize is the size of
the C long type.  In particular, this is not true on 64 bit Windows.

Notably, this fixes the hash equality between tinyarrays and tuples on
64 bit Windows where long is only 32 bit.  The changes shouldn't have
any observable effect (other than a minor speedup) on Unix.

this fixes object size calculation. The previous implementation
did not work in cases where the datatype stored in the tinyarray
is narrower than a machine word, and the compiler padded
'Array_base' to be word-aligned.

The more complicated implementation that we had previously,
(which was copied not-quite-verbatim from
https://github.com/python/cpython/blob/master/Objects/longobject.c#L3031)
is not necessary because hashing for integers is just the integer
itself modulo _PyHASH_MODULUS (being careful with the sign).

This bug only seems to materialize on Windows, but now the types match
https://github.com/python/cpython/blob/master/Objects/longobject.c#L3031
Also inline 'old_hash', now that it is used in a single place only.

'sys.maxsize' refers to the size of a 'Py_size_t', whereas
ndarray_int's internally store a 'long'. We now correctly test
for hash equality within the relevant integer limits.

This is useful for testing

Also define 'Py_uhash_t'. This increases parity between the
tinyarray hashing code and CPython's. Note that in Python2
hashes were long integers, whereas in Python 3 they are size_t.

Numpy 1.12.0 updated iscomplexobj which always shows False for
tinyarrays, which makes assert_almost_equal fail for complex
array-valued arguments, as they will not be split up into real and
imaginary part. We circumvent this bug by testing every entry
separately in this case. This bug will be fixed for Numpy 1.12.1.

Fixes #11

This silences the warning about "invalid suffix on literal".

These two options are pure setuptools functionality and problematic:
https://pip.pypa.io/en/stable/user_guide/?highlight=setup_requires#installation-bundles

Also fixes other memory leads. Previously, load_index_seq_as_long did
not correctly DECREF the new reference created by PySequence_Fast.

fixes #10