Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn

PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:

struct PLDHashEntryHdr {
  // PLDHashNumber is a uint32_t.
  PLDHashNumber mKeyHash; // Cached hash key for object.
};

class MyType : public PLDHashEntryHdr {
  // Data members, etc.
};

PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.

Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:

MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...

The padding at offset 4 is dead, unused space.

We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly.  But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).

As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top.  We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.

Author: froydnj