Reverted due to an internally discovered lld crash due to the underlying
StringMap changes, which turned out to be an existing lld bug that got
tickled by the StringMap changes. That's addressed in
dee8786f70a3d62b639113343fa36ef55bdbad63 so let's have another go with
this change.

Original commit message:
    lldb was rehashing the string 3 times (once to determine which StringMap
    to use, once to query the StringMap, once to insert) on insertion (twice
    on successful lookup).

    This patch allows the lldb to benefit from hash improvements in LLVM
    (from djbHash to xxh3).

    Though further changes would be needed to cache this value to disk - we
    shouldn't rely on the StringMap::hash remaining the same in the
    future/this value should not be serialized to disk. If we want cache
    this value StringMap should take a hashing template parameter to allow
    for a fixed hash to be requested.

This reverts commit 5bc1adff69315dcef670e9fcbe04067b5d5963fb.
Effectively reapplying the original 2e197602305be18b963928e6ae024a004a95af6d.

Underlying StringMap API for providing a hash has caused some problems
(observed a crash in lld) - so reverting this until I can figure out/fix
what's going on there.

This reverts commit 52ba075571958e2fec8d871ddfa1ef56486b86d3.
This reverts commit 2e197602305be18b963928e6ae024a004a95af6d.

lldb was rehashing the string 3 times (once to determine which StringMap
to use, once to query the StringMap, once to insert) on insertion (twice
on successful lookup).

This patch allows the lldb to benefit from hash improvements in LLVM
(from djbHash to xxh3).

Though further changes would be needed to cache this value to disk - we
shouldn't rely on the StringMap::hash remaining the same in the
future/this value should not be serialized to disk. If we want cache
this value StringMap should take a hashing template parameter to allow
for a fixed hash to be requested.

StringRef was made to be passed by value efficiently.

Differential Revision: https://reviews.llvm.org/D152010

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

Remove ConstString::StaticMemorySize as it is unused and superseded by
GetMemoryStats. It is referenced in a bunch of doc comments but I don't
really understand why. My best guess it that the comments were
copy-pasted from ConstString::MemorySize() even though it didn't make
sense there either. The implementation of StaticMemorySize was being
called on the MemoryPool, not on the ConstString itself.

Differential revision: https://reviews.llvm.org/D118091

Add statistics about the memory usage of the string pool. I'm
particularly interested in the memory used by the allocator, i.e. the
number of bytes actually used by the allocator it self as well as the
number of bytes allocated through the allocator.

Differential revision: https://reviews.llvm.org/D117914

The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084

This reverts "Eliminate unneeded value parameters in Utility" for
ConstString. As Pavel pointed out on the mailing list, the class *is*
trivially copyable.