These can be represented by the same definition. It is just a
RegisterOperand wrapper for a VGPR register class with a DecoderMethod
override.
NFC.

The AV operand classes should be used directly at the top level
of the load/store definitions. Inline the remaining use into the
strange MUBUF TFE vs. non-TFE usecase, which needed a special case
for 16-bit operands anyway.

 (#157037)

This regresses the assembler diagnostics. I made some attempts
at avoiding this, but it turns out the way we manage these
is really wrong. We're completely ignoring the reported missing
features from MatchInstructionImpl and also don't have properly
configured predicates to automatically get the message.

Start stripping out the uses of getLdStRegisterOperand. This
added a confusing level of indirection where the class at the
definition point was not the actual class used. This was also
pulling in the AV class usage for targets where it isn't
relevant. This was also inflexible for special cases.

Also fixes using default arguments which only served to wrap the
class argument in a RegisterOperand.

This should be done for all the memory instructions.

The instruction definitions for loads and stores do not
accurately model the operand constraints of loads and stores
with AGPRs. They use AV register classes, plus a hack
a hack in getRegClass/getOpRegClass to avoid using AGPRs or
AV classes with the multiple operand cases, but it did not
consider the 3 operand case.

Model this correctly by using separate all-VGPR and all-AGPR
variants for the cases with multiple data operands.

This does regress the assembler errors on gfx908 for the
multi-operand cases. It now reports a generic operand
invalid error for GPU instead of the specific message
that agpr loads and stores aren't supported.

In the future AMDGPURewriteAGPRCopyMFMA should be taught
to replace the VGPR forms with the AGPR ones.

Most of the diff is fighting the DS pseudo structure. The
mnemonic was being used as the key to SIMCInstr, which is a
collision in the AGPR case. We also need to go out of our way
to make sure we are using the gfx9+ variants of the pseudos
without the m0 use. The DS multiclasses could use a lot of
cleanup.

Fixes #155777