getAsmString returns StringRef now. Fixes build for the DirectX backend.

With this change, some callers get to use StringRef::starts_with.

I'm planning to teach getAsmString to return StringRef also, but
I'ld like to keep that separate from this patch.

commit:
https://github.com/llvm/llvm-project/commit/68947342b75cc71f3ac9041d11db086d8d074336
added a new `writeDIFixedPointType` function.
However, `DIFixedPointType` is not supported in DXIL so we need to add a
fail fast case for this to fix the build.

this change fixes a build break introduced by
https://github.com/llvm/llvm-project/pull/129596

The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.

For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.

The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.

1. Fix build break caused by #126772 by adding `writeDISubrangeType`
stub to `DXILBitcodeWriter.cpp`
2. Fix build break caused by #128480 by adding implementation of pure
virtual method `TargetSubtargetInfo::getRegisterInfo`

This PR removes the old `nocapture` attribute, replacing it with the new
`captures` attribute introduced in #116990. This change is
intended to be essentially NFC, replacing existing uses of `nocapture`
with `captures(none)` without adding any new analysis capabilities.
Making use of non-`none` values is left for a followup.

Some notes:
* `nocapture` will be upgraded to `captures(none)` by the bitcode
   reader.
* `nocapture` will also be upgraded by the textual IR reader. This is to
   make it easier to use old IR files and somewhat reduce the test churn in
   this PR.
* Helper APIs like `doesNotCapture()` will check for `captures(none)`.
* MLIR import will convert `captures(none)` into an `llvm.nocapture`
   attribute. The representation in the LLVM IR dialect should be updated
   separately.

PointerUnion's `is`, `get`, and `dyn_cast` have been deprecated in
favour of using `isa`, `cast`, and `dyn_cast` directly. Migrate these
uses over.

Translate modern LLVM fast math flags to LLVM 3.7 equivalent in DXIL
bitcode. Mostly use patch from #120630
Closes #120630

When emitting references to functions as part of `ValueAsMetadata`,
we currently emit the incorrect (typed) pointer, resulting in
crashes during deserialization. Avoid this by correctly mapping the
type during serialization.

It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.

This _incompatibly_ changes the ABI of any LLVM IR function with
`x86_mmx` arguments or returns: instead of passing in mmx registers,
they will now be passed via integer registers. However, the real-world
incompatibility caused by this is expected to be minimal, because Clang
never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>`
or `double`, depending on ABI.

This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type.
That type simply no longer corresponds to an IR type, and is used only
by MMX intrinsics and inline-asm operands.

Because SelectionDAGBuilder only knows how to generate the
operands/results of intrinsics based on the IR type, it thus now
generates the intrinsics with the type MVT::v1i64, instead of
MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus
have the X86 backend fix them up in DAGCombine. (This may be a
short-lived hack, if all the MMX intrinsics can be removed in upcoming
changes.)

Works towards issue #98272.