This reverts commit 6a0d6fc2e92bcfb7cb01a4c6cdd751a9b4b4c159.

This reverts commit 1afb81dfaf902c1c42bd91fec1a7385e6e1529d3.

This update enhances the implementation of structural hashing for global
variables, using their initial contents. Private global variables or
constants are often used for metadata, where their names are not unique.
This can lead to the creation of different hash results although they
could be merged by the linker as they are effectively identical.
- Refine the hashing of GlobalVariables for strings or certain
Objective-C metadata cases that have section names. This can be further
extended to other scenarios.
- Expose StructuralHash for GlobalVariable so that this API can be
utilized by MachineStableHashing, which is also employed in the global
function outliner.

This change significantly improves size reduction by an additional 1% on
the LLD binary when the global function outliner and merger are enabled
together. As discussed in the RFC
https://discourse.llvm.org/t/loh-conflicting-with-machineoutliner/83279/8?u=kyulee-com,
if we disable or relocate the LOH pass, the size impact could increase
to 4%.

Identified with misc-include-cleaner.

LLVM often extends global names by adding suffixes to distinguish unique
identities. However, these suffixes are not always stable across
different runs and build environments. To address this issue, I
implemented `get_stable_name` to ignore such suffixes and obtain the
original name. This approach is not new, as PGO or Bolt already handle
this issue similarly. Using the stable name obtained from
`get_stable_name`, I implemented `stable_hash_name` while utilizing the
same underlying `xxh3_64bit` algorithm as before.

This is a follow-up to address a suggestion from
https://github.com/llvm/llvm-project/pull/105619.
The main goal of this change is to efficiently implement stable hash
functions using the xxh3 64bits API.
`stable_hash_combine_range` and `stable_hash_combine_array` functions
are removed and consolidated into a more general `stable_hash_combine`
function that takes an `ArrayRef<stable_hash>` as input.

I found the current stable hash is not deterministic across multiple
runs on a specific platform. This is because it uses `hash_combine`
instead of `stable_hash_combine`.

FNV, used by stable_hash_combine_string is extremely slow. For string
hashing with good avalanche effects, we prefer xxh3_64bits.

StableHashing.h might still be useful as it provides a stable
hash_combine while Hashing.h's might be non-deterministic (#96282).

Pull Request: https://github.com/llvm/llvm-project/pull/100668

This is part of #70452 that changes the type used for the external
interface of MMO to LocationSize as opposed to uint64_t. This means the
constructors take LocationSize, and convert ~UINT64_C(0) to
LocationSize::beforeOrAfter(). The getSize methods return a
LocationSize.

This allows us to be more precise with unknown sizes, not accidentally
treating them as unsigned values, and in the future should allow us to
add proper scalable vector support but none of that is included in this
patch. It should mostly be an NFC.

Global ISel is still expected to use the underlying LLT as it needs, and
are not expected to see unknown sizes for generic operations. Most of
the changes are hopefully fairly mechanical, adding a lot of getValue()
calls and protecting them with hasValue() where needed.