Previous implementation had an issues:
- macros murmur1 assumes murmur_step takes rotation value
  as a second argument
- but murmur_step second argument is "next block"
- this makes st_hash_uint and st_hash_end to not mix high bits of
  hash value into lower bits
- this leads to pure hash behaviour on doubles and other.
  It didn't matter when bins amount were prime numbers, but it hurts
  when bins are powers of two.

Mistake were created when implementor tries to co-exist Murmur1 and Murmur2
in a same code.

Change it to single "Murmur3" implementation.
It is not exact implementation:
- 64bit version is an extrapolation of 32bit version instead of
  separate algorithm
- 64bit finalizer is taken from
  http://zimbry.blogspot.ru/2011/09/better-bit-mixing-improving-on.html
- on final block call murmur_step (do not shortcut last rotation of h
  and multiplication) instead of custom block.

Also remove ST_USE_FNV1: it lack many function, and looks to be abandoned

Main Murmur weakness is permutation of a block without seed.
Just adding a random seed to each block and finalization we
greatly increase security of Murmur.

SipHash is secure PseudoRandom Function, and could be used
in a counter mode to produce strong pseudorandom stream of bytes.
So use it to securely initialize both hashseed and sipseed.
(so no way to recover sipseed from hashseed)

Note, that ident becomes a bit slower, cause hash value is more "random".
New versions calculates fair hash value, and so provides statistically
fair collision rate.
Previous version relies on internal pattern of symbols and "usually" provides
lesser collisions. Though it could be compromised easely.

…hash24

SipHash13 is secure enough to be used in hash-tables,
and SipHash's author confirms that.
Rust already considered switch to SipHash13:
  rust-lang/rust#29754 (comment)
Jean-Philippe Aumasson confirmation:
  rust-lang/rust#29754 (comment)
Merged pull request:
  rust-lang/rust#33940

While for cryptography it has halved security, it is just enough
for hash tables.
See Jean-Philipee Aumasson answeres to Ocaml pull request:
ocaml/ocaml#24 (comment)
ocaml/ocaml#24 (comment)

- instead of allocating st_table_entry per element with malloc,
  store all elements in one array
- use order in the array as an insertion order instead of list
-- after array's last element is filled, hash is rebuilt and grow/shrunk if needed.
- reduce sizeof(st_table_entry) to 24byte on 64bit platform by default
-- use 32bit next index instead of pointer and 32bit hash
-- there is compile time option to use 64bit index and 64bit hash
   to have ability to use huge hashes.
- reduce sizeof(st_table) to 32bytes (on x86_64) by couple of tricks:
-- alloc bins together with entries, so only 1 pointer needed
-- pack allocated size into 8bit and rebuilt count into 24bit
- fix test_st_foreach
-- disable test_st_foreach(:unpack_delete) cause it behaves differently
   on already unpacked table (it may lead to segfault in previous st
   implementation)
-- remove checks for packed/unpacked
- bins are dinamically sized:
-- if array's size is less than 256, then bins are 8bit indices
-- if array is less than 65536 elements, then bins are 16bit indices
-- otherwise bins are indices of maximum size (32bit or 64bit depending
   on architecture and compile time option)