This patch uses "if constexpr" whenever we call shouldReverseIterate
in "if" conditions.  Note that shouldReverseIterate is a constexpr
function.

These are already zeroinitialized in the field definitions.

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.

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

Original commit message:
    Useful for lldb's const string pool, using the hash to determine which
    string map to lock and query/insert.

    Derived from https://reviews.llvm.org/D122974 by Luboš Luňák

This reverts commit f976719fb2cb23364957e5993f7fc3684ee15391.
Effectively reapplying 67c631d283fc96d652304199cd625be426b98f8e.

Crash identified internally in lld's use of StringMap in
`compareSections`. Will investigate offline before recommitting.

This reverts commit 67c631d283fc96d652304199cd625be426b98f8e.

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.

Useful for lldb's const string pool, using the hash to determine which
string map to lock and query/insert.

Derived from https://reviews.llvm.org/D122974 by Luboš Luňák

Similar to D142862.

xxh3 is significantly faster than xxh64. Switch to xxh3, as we did for
for lld and llvm-dwarfutil to increase performance (D154813 D155675).
While I think StringMap is not a bottleneck for most applications, it
seems good to eliminate the slower xxh64.
In addition, according to Erik Desjardins, an artificial benchmark of
Rust with very large constant strings improves by ~3% locally.

I have fixed all found issues (~20) separately, but one is remaining:

* ExecutionEngine/RuntimeDyld/ARM/MachO_ARM_PIC_relocations.s has a
  failure due to StringMap iteration order. It now passes
  with LLVM_ENABLE_REVERSE_ITERATION=on while failing with
  LLVM_ENABLE_REVERSE_ITERATION=off.

Reviewed By: erikdesjardins

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

ProgrammersManual.html says

> StringMap iteration order, however, is not guaranteed to be deterministic, so any uses which require that should instead use a std::map.

This patch makes -DLLVM_REVERSE_ITERATION=on (currently
-DLLVM_ENABLE_REVERSE_ITERATION=on works as well) shuffle StringMap
iteration order (actually flipping the hash so that elements not in the
same bucket are reversed) to catch violations, similar to D35043 for
DenseMap. This should help change the hash function (e.g., D142862,
D155781).

With a lot of fixes, there are still some violations. This patch
implements the "reverse_iteration" lit feature to skip such tests.
Eventually we should remove this feature.

`ninja check-{llvm,clang,clang-tools}` are clean with
`#define LLVM_ENABLE_REVERSE_ITERATION 1`.

Reviewed By: jhenderson

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