faster StringTable

- use a hash table with open addressing and linear probing
  for better cache locality
reserve enough initial capacity to avoid hash table resizes

- based on numbers from phobos compilation
use triangular numbers for probing

- guaranteed to visit every bucket in a power of 2 sized hash table

- mitigates clustering problem (with many hash collisions) while still preserving
  good cache locality
use MurmurHash2

- much better distribution leads to less collisions
  and thus to faster lookup

- also faster
reduce StringEntry size from 16 to 8 byte

- more cache hits

- allocate StringValues from pools in StringTable
  and reference them with a 32-bit index+offset

- hash was only 32-bit anyhow so use uin32_t instead of hash_t
StringEntry as POD

- call getValue(vptr) in findSlot only when hash
  matches (saves a possibly unnecessary load)
Merge pull request #4088 from MartinNowak/fasterStringTable

faster string table