The existing function is LT but most of the uses are better
expressed as GE

Clang and other frontends generally need the LLVM data layout string in
order to generate LLVM IR modules for LLVM. MLIR clients often need it
as well, since MLIR users often lower to LLVM IR.

Before this change, the LLVM datalayout string was computed in the
LLVM${TGT}CodeGen library in the relevant TargetMachine subclass.
However, none of the logic for computing the data layout string requires
any details of code generation. Clients who want to avoid duplicating
this information were forced to link in LLVMCodeGen and all registered
targets, leading to bloated binaries. This happened in PR #145899,
which measurably increased binary size for some of our users.

By moving this information to the TargetParser library, we
can delete the duplicate datalayout strings in Clang, and retain the
ability to generate IR for unregistered targets.

This is intended to be a very mechanical LLVM-only change, but there is
an immediately obvious follow-up to clang, which will be prepared
separately.

The vast majority of data layouts are computable with two inputs: the
triple and the "ABI name". There is only one exception, NVPTX, which has
a cl::opt to enable short device pointers. I invented a "shortptr" ABI
name to pass this option through the target independent interface.
Everything else fits. Mips is a bit awkward because it uses a special
MipsABIInfo abstraction, which includes members with codegen-like
concepts like ABI physical registers that can't live in TargetParser. I
think the string logic of looking for "n32" "n64" etc is reasonable to
duplicate. We have plenty of other minor duplication to preserve
layering.

---------

Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>

This pr implements support for a root signature as a target, as specified
[here](https://github.com/llvm/wg-hlsl/blob/main/proposals/0029-root-signature-driver-options.md#target-root-signature-version).

This is implemented in the following steps:
1. Add `rootsignature` as a shader model environment type and define
`rootsig` as a `target_profile`. Only valid as versions 1.0 and 1.1
2. Updates `HLSLFrontendAction` to invoke a special handling of
constructing the `ASTContext` if we are considering an `hlsl` file and
with a `rootsignature` target
3. Defines the special handling to minimally instantiate the `Parser`
and `Sema` to insert the `RootSignatureDecl`
4. Updates `CGHLSLRuntime` to emit the constructed root signature decl
as part of `dx.rootsignatures` with a `null` entry function
5. Updates `DXILRootSignature` to handle emitting a root signature
without an entry function
6. Updates `ToolChains/HLSL` to invoke `only-section=RTS0` to strip any
other generated information

Resolves: https://github.com/llvm/llvm-project/issues/150286.

##### Implementation Considerations
Ideally we could invoke this as part of `clang-dxc` without the need of
a source file. However, the initialization of the `Parser` and `Lexer`
becomes quite complicated to handle this.

Technically, we could avoid generating any of the extra information that
is removed in step 6. However, it seems better to re-use the logic in
`llvm-objcopy` without any need for additional custom logic in
`DXILRootSignature`.

fixes #156068

- We needed to add a new sub arch to the target tripple so we can test
that emulation does not happen when targeting SM6.9
- The HLSL toolchain needed to be updated to handle the conversion of
strings to enums for the new sub arch.
- The emulation is done in DXILIntrinsicExpansion.cpp and needs to be
able to convert both llvm.is.fpclass and lvm.dx.isinf to the proper
emulation
- test updates in TargetParser/TripleTest.cpp, isinf.ll, is_fpclass.ll,
and DXCModeTest.cpp

For context, CheriotRTOS is a custom RTOS co-designed for the CHERIoT
CHERI-enabled RISCV32E platform. It uses a custom ABI and linkage model,
necesitating representing it in the target triple.

Ref:
https://ai.meta.com/blog/next-generation-meta-training-inference-accelerator-AI-MTIA/
This PR contains 
1. MTIA: Meta Training and Inference Accelerator as Environment.
2. Meta as the vendor.


### Testing 
Added a unittest for the relevant changes

### Reviewers
@clayborg , @jeffreytan81 , @Jlalond

Fixes asserting with windows-elf triples. Should fix regression
reported in https://github.com/llvm/llvm-project/pull/147225#issuecomment-3054190938

I'm not sure this is a valid triple, but I'm guessing the MCJIT usage
is an accident. This does change the behavior from trying to use WinEH
to DwarfCFI; however the backend crashes with WinEH so I'm assuming following
ELF is the more correct option.

I encountered the assertion failure `Assertion
TmpAsmInfo->getExceptionHandlingType() ==
getTargetTriple().getDefaultExceptionHandling() && "MCAsmInfo and Triple
disagree on default exception handling type"' failed`.

Currently the default exception handling type is scattered
across the backends in MCAsmInfo constructors. Allow this
to be computed from the triple so the IR can centrally determine
the set of ABI calls.

Manually submitting, closes #147225