I noticed, when examining the generated Asm Matcher table, that some of
these custom immediate operands are missing, and so we are not parsing
some hint aliases into the correct MCInst.
Where this becomes apparent is when you parse e.g. hint #7 into an
MCInst - without these cases, it becomes the MCInst (HINT 17), which
will always be printed as hint #17. With these cases, it becomes the
MCInst XPACLRI, which will be printed as xpaclri with pauth, or
hint #17 without, matching how xpaclri is parsed.
We only handle some specific hint aliases in this manner, usually where
these hints have specific effects that need to be modelled for accurate
code-generation. Otherwise, we just use the normal InstAlias system
to have the aliases parsed into a (HINT N) MCInst.
These could do with being reordered numerically