These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.

Part of the coverage-tracking feature, following #107279.

In order for DebugLoc coverage testing to work, we firstly have to set
annotations for intentionally-empty DebugLocs, and secondly we have to
ensure that we do not drop these annotations as we propagate DebugLocs
throughout compilation. As the annotations exist as part of the DebugLoc
class, and not the underlying DILocation, they will not survive a
DebugLoc->DILocation->DebugLoc roundtrip. Therefore this patch modifies
a number of places in the compiler to propagate DebugLocs directly
rather than via the underlying DILocation. This has no effect on the
output of normal builds; it only ensures that during coverage builds, we
do not drop incorrectly annotations and therefore create false
positives.

The bulk of these changes are in replacing
DILocation::getMergedLocation(s) with a DebugLoc equivalent, and in
changing the IRBuilder to store a DebugLoc directly rather than storing
DILocations in its general Metadata array. We also use a new function,
`DebugLoc::orElse`, which selects the "best" DebugLoc out of a pair
(valid location > annotated > empty), preferring the current DebugLoc on
a tie - this encapsulates the existing behaviour at a few sites where we
_may_ assign a DebugLoc to an existing instruction, while extending the
logic to handle annotation DebugLocs at the same time.

The current implementation always creates a 1 bit constant for the
result of the `G_ICMP`, which will cause issues if the destination
register size is larger than that. With asserts enabled, it will cause a
crash in `buildConstant`:
```
llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp:322: virtual MachineInstrBuilder llvm::MachineIRBuilder::buildConstant(const DstOp &, const ConstantInt &): Assertion `EltTy.getScalarSizeInBits() == Val.getBitWidth() && "creating constant with the wrong size"' failed. 
```

Allow construction of DstOp with VRegAttrs.
Also allow construction with register class or bank and LLT.
Intended to be used in lowering code for reg-bank-select where
new registers need to have both register bank and LLT.
Add support for new type of DstOp in CSEMIRBuilder.

As far as I can tell, this pull request was not approved, and
did not go through an RFC on discourse.

This reverts commit 89881480030f48f83af668175b70a9798edca2fb.
This reverts commit 225d8fc8eb24fb797154c1ef6dcbe5ba033142da.

Currently, on different platform, the behaivor of llvm.minnum is
different if one operand is sNaN:

When we compare sNaN vs NUM:

ARM/AArch64/PowerPC: follow the IEEE754-2008's minNUM: return qNaN.
RISC-V/Hexagon follow the IEEE754-2019's minimumNumber: return NUM. X86:
Returns NUM but not same with IEEE754-2019's minimumNumber as
     +0.0 is not always greater than -0.0.
MIPS/LoongArch/Generic: return NUM.
LIBCALL: returns qNaN.

So, let's introduce llvm.minmumnum/llvm.maximumnum, which always follow
IEEE754-2019's minimumNumber/maximumNumber.

Half-fix: #93033

Make sure to merge the sourcelocation of the Dominating Instruction that
is hoisted in a basic block in the CSEMIRBuilder in the legalizer pass.

If this is not done, we can have a incorrect line table entry that makes
the instruction pointer jump around.

For example the line table without this patch looks like:

```
Address            Line   Column File   ISA Discriminator OpIndex Flags
------------------ ------ ------ ------ --- ------------- ------- -------------
0x0000000000000000      0      0      1   0             0       0  is_stmt
0x0000000000000010     11     14      1   0             0       0  is_stmt prologue_end
0x0000000000000028     12      1      1   0             0       0  is_stmt
0x000000000000002c     12     15      1   0             0       0
0x000000000000004c     12     13      1   0             0       0
0x000000000000005c     13      1      1   0             0       0  is_stmt
0x0000000000000064     12     13      1   0             0       0  is_stmt
0x000000000000007c     13      7      1   0             0       0  is_stmt
0x00000000000000c8     13      1      1   0             0       0
0x00000000000000e8     13      1      1   0             0       0  epilogue_begin
0x00000000000000f8     13      1      1   0             0       0  end_sequence
```

The line table entry for 0x000000000000005c should be 0

After this patch, the line table looks like:

```
Address            Line   Column File   ISA Discriminator OpIndex Flags
------------------ ------ ------ ------ --- ------------- ------- -------------
0x0000000000000000      0      0      1   0             0       0  is_stmt
0x0000000000000010     11     14      1   0             0       0  is_stmt prologue_end
0x0000000000000028     12      1      1   0             0       0  is_stmt
0x000000000000002c     12     15      1   0             0       0 
0x000000000000004c     12     13      1   0             0       0 
0x000000000000005c      0      0      1   0             0       0 
0x0000000000000064     12     13      1   0             0       0 
0x000000000000007c     13      7      1   0             0       0  is_stmt
0x00000000000000c8     13      1      1   0             0       0 
0x00000000000000e8     13      1      1   0             0       0  epilogue_begin
0x00000000000000f8     13      1      1   0             0       0  end_sequence
```

This patch tries to fold `G_ICMP` if possible.

This patch tries to fold `G_CTTZ` if possible.

Recommits llvm/llvm-project#80378 which was reverted in
llvm/llvm-project#84330. The problem was that the change in
llvm/test/CodeGen/AArch64/GlobalISel/legalizer-info-validation.mir used
217 as an opcode instead of a regex.