Use new hashtable for hashes

[zuiderkwast]

The new hashtable doesn't have a dict entry, so we need to invent one to hold field and value.

Possibly, we can embed field or value or both. The method used earlier is the function sdscopytobuffer and a byte to store the size of the sds header.

A field name never changes so it seems safe to always embed the field name, while the value can change and it can be very large so we can allow it to be non-embedded. This is very similar to string keys with the EMBSTR vs RAW encoding.

Idea of layout with both embedded:

+-----------------------------+-----------------------------+
| field                       | value                       |
| hdr-size | hdr | content \0 | hdr-size | hdr | content \0 |
+-----------------------------+-----------------------------+

Idea of layout with field embedded, value as pointer, stored first to make it aligned. (#1502 simply uses this representation for all field-value pairs.)

+-------+-----------------------------+
| value | field                       |
| ptr   | hdr-size | hdr | content \0 |
+-------+-----------------------------+

To distinguish between different representations, we could use the LSB bits in the pointer to it, the pointer stored in the hashtable. (This solution was not chosen in #1579.)

 hashtable
+----------+        +-----------+----------------+
| ptr  000 -------->| value-ptr | embedded field |
|          |        +-----------+----------------+
|          |
|          |        +----------------+----------------+
| ptr  001 -------->| embedded field | embedded value |
|          |        +----------------+----------------+
| ...      |
+----------+

Another way to indicate different kinds of entries is to use some bits in the sds header of the field. That's the chosen representation in #1579.