Cap unification bits for functor

In SWI's entire Prolog code base, functors have about 13 bits of
entropy.  If unification hashing for a compound term would allocate
more than 13 bits for the functor, cap the functor at 13 bits and use
the saved bits for arguments.  This should use our bit budget more
effectively.

If splitting our bit budget among the arguments leaves some bits
unused, because of rounding errors, allocate those extra bits back to
the functor.  It's better to use them there than to waste them.

This algorithm maintains the important invariant that a given compound
term always allocates its bit budget the same way based only on the
term's arity.

This change improves performance for DCGish benchmark but hurts it for
Append, Maplist and NaiveReverse.  I hope to recover those performance
losses shortly.
Smarter unification hashes for integers

When Prolog unifies integers, those integers are almost always small
(less than 1,000).  On that scale, the least significant bits clearly
distinguish one integer from another.  That's the purpose of a
unification hash, so just use those bits as the hash.  By hashing the
hexadecimal representation, the old code actually increased the
chances of a hash collision for small integers.

Large integers continue to use the old code path.

On a production language model benchmark which uses quite a few code
lists, this change improves performance by 13%.
Add missing cases to Is{Integer,Float}
Special unification hash for pairs

Pairs are most often used to build lists.  Repeatedly hashing the '.'
functor at each level of the list wastes valuable bits.  By skipping
the functor for pairs, the list content contributes to more of the
unification hash which should make the hashes more selective.

This makes my production language model test about 1% faster.
Hash string's codepoints directly

This avoids a memory allocation when converting from a string into
[]byte.