In the process of determining whether two MachineOperands are equal and
calculating the hash of a MachineOperand, both MO_RegisterMask and
MO_RegisterLiveOut types were uniformly handled. However, when the type
is MO_RegisterLiveOut, calling getRegMask() triggers an assertion
failure. This PR addresses this issue.

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