Use MCRegister instead of MCPhysReg or use MCRegister::id().

In GFX10+, the v_cmpx_* instructions use EXEC as the implicit dst and do
not have explicit dst. Therefore a warning is issued by the disassembler
when the dst is not EXEC. However, in GFX9 and earlier, those
instructions have EXEC as the implicit dst as well as an explicit dst.
The aforementioned warning should not be issued.

Fixes round-tripping where literals used to be reassembled into
inline constants.

Also fix the %extract-encodings substitution in lit tests to emit
each instruction code once and not twice.

Eliminate the Literal64 field.

There should normally be no need to generate implicit lit64()
modifiers on the assembler side. It's the encoder's responsibility
to recognise literals that are implicitly 64 bits wide.

The exceptions are where we rewrite floating-point operand values
as integer ones, which would not be assembled back to the original
values unless wrapped into lit64().

Respect explicit lit() modifiers for non-inline values as
necessary to avoid regressions in MC tests. This change still
doesn't prevent use of inline constants where lit()/lit64 is
specified; subject to a separate patch.

On disassembling, only create lit64() operands where necessary for
correct round-tripping.

Add round-tripping tests where useful and feasible.

This removes special case processing in TargetInstrInfo::getRegClass to
fixup register operands which depending on the subtarget support AGPRs,
or require even aligned registers.

This regresses assembler diagnostics, which currently work by hackily
accepting invalid cases and then post-rejecting a validly parsed
instruction.
On the plus side this now emits a comment when disassembling unaligned
registers for targets with the alignment requirement.

There is no test change at this moment because we don't have a target
that has this feature by default yet.

And rework the lit64() support to use it.

The rules for when to add lit64() can be simplified and
improved. In this change, however, we just follow the existing
conventions on the assembler and disassembler sides.

In codegen we do not (and normally should not need to) add explicit
lit() and lit64() modifiers, so the codegen tests lose them. The change
is an NFCI otherwise.

Simplifies printing operands.

This was additional hacking around using incorrect register class
constraints for paired data operands. I'm not really sure why we
need any of what's left. In particular the IS_VGPR special case
seems backwards from how the encoding works.

This reverts commit be17791f2624f22b3ed24a2539406164a379125d.

This is not necessary for gfx1250 anymore.

GFX12+ buffer ops require positive InstOffset per AMD hardware spec.
Modified assembler/disassembler to reject negative buffer offsets.