Even if it is a debugging command, make sure that when it forces a
change in encoding, the command is propagated.

If we converted to dense, a register must be updated in the dense
representation.

Mostly by reordering opcodes check conditional by frequency of opcodes
in larger sparse-encoded HLLs.

Bottleneck found profiling. Big run time improvement found when testing
after the change.

As more values are added splitting ZERO or XZERO opcodes, try to merge
adjacent VAL opcodes if they have the same value.

Now the macros will work with arguments such as "ptr+1".

Bulk length for registers was emitted too early, so if there was a bug
the reply looked like a long array with just one element, blocking the
client as result.

We want to promote if the total string size exceeds the resulting size
after the upgrade.

The function checks if all the HLL_REGISTERS were processed during the
convertion from sparse to dense encoding, returning REDIS_OK or
REDIS_ERR to signal a corruption problem.

A bug in PFDEBUG GETREG was fixed: when the object is converted to the
dense representation we need to reassign the new pointer to the header
structure pointer.

Provides a human readable description of the opcodes composing a
run-length encoded HLL (sparse encoding).
The command is only useful for debugging / development tasks.

PFDEBUG will be the interface to do debugging tasks with a key
containing an HLL object.

The new API takes directly the object doing everything needed to
turn it into a dense representation, including setting the new
representation as object->ptr.

sdsIncrLen() must be called anyway even if we are replacing the last
oppcode of the sparse representation.

Two vars initialized to wrong values in createHLLObject().

The function didn't considered the fact that each XZERO opcode is
two bytes.

Code never tested, but the basic layout is shaped in this commit.
Also missing:

1) Sparse -> Dense conversion function.
2) New HLL object creation using the sparse representation.
3) Implementation of PFMERGE for the sparse representation.

Also dense representation access macro renamed accordingly.

Metadata are now placed at the start of the representation as an header.
There is a proper structure to access the representation.
Still work to do in order to truly abstract the implementation from the
representation, commands still work assuming dense representation.

After running a few simulations with different alternative encodings,
it was found that the VAL opcode performs better using 5 bits for the
value and 2 bits for the run length, at least for cardinalities in the
range of interest.

adjustOpenFilesLimit() and clusterUpdateSlotsWithConfig() that were
assuming uint64_t is the same as unsigned long long, which is true
probably for all the systems out there that we target, but still GCC
emitted a warning since technically they are two different types.

This will be a non-op most of the times since the object will be
unshared / decoded, however it is more technically correct to start this
way since the object may be decoded even in the read-only code path.

We also avoid to re-create an object that is already in EMBSTR encoding.

Using a seed of zero has the side effect of having the empty string
hashing to what is a very special case in the context of HyperLogLog: a
very long run of zeroes.

This did not influenced the correctness of the result with 16k registers
because of the harmonic mean, but still it is inconvenient that a so
obvious value maps to a so special hash.

The seed 0xadc83b19 is used instead, which is the first 64 bits of the
SHA1 of the empty string.

Reference: issue #1657.