arm64/instgen: add arm64 ISA XML processing

This CL proceeds with processing the unmarshalled XML file and process them
into data that can be used for code generation to the assembler.

The processing is to understand the <asmtemplate> field in the XML data and
populate the Inst structure with more comprehensive unexported fields marked
under comment:

```
// The fields below are the parsed results of the XML files.
```

You can find those fields in inst.go, they are all unexported.

And example parsed data looks like this:
(for instruction ADD predicated
https://developer.arm.com/documentation/111108/2025-12/SVE-Instructions/ADD--vectors--predicated---Add--predicated--?lang=en)
- parsed data in RegDiagram
--- Parsed Data ---
  fixedBin: 0x4000000
  mask: 0xff3fe000
  varBin:
    size: [22, 24]
    Pg: [10, 13]
    Zm: [5, 10]
    Zdn: [0, 5]
  parsed: true
--- Parsed Data ---

- parsed data in Encoding
--- Parsed Data ---
  binary: 0x4000000
  mask: 0xff3fe000
  asm: ADD  <Zdn>.<T>, <Pg>/M, <Zdn>.<T>, <Zm>.<T>
  goOp: AZADD
  arm64Op: A64ADD
  class: C_SVE
  invalid: false
  alias: false
  prefix: AZ
  operands:
    operand{
      name: ADD
      typ:
      elems:
    }
    operand{
      name: <Zm>.<T>
      typ: AC_ARNG
      elems:
        element{
          encodedIn: Zm
          textExp: Is the name of the second source scalable vector register, encoded in the "Zm" field.
          symbol: <Zm>
        }
        element{
          encodedIn: size
          textExp: size   <T>
          00      B
          01      H
          10      S
          11      D
          symbol: <T>
        }
    }
    operand{
      name: <Zdn>.<T>
      typ: AC_ARNG
      elems:
        element{
          encodedIn: Zdn
          textExp: Is the name of the first source and destination scalable vector register, encoded in the "Zdn" field.
          symbol: <Zdn>
        }
        element{
          encodedIn: size
          textExp: size   <T>
          00      B
          01      H
          10      S
          11      D
          symbol: <T>
        }
    }
    operand{
      name: <Pg>/M
      typ: AC_PREGM
      elems:
        element{
          encodedIn: Pg
          textExp: Is the name of the governing scalable predicate register P0-P7, encoded in the "Pg" field.
          symbol: <Pg>
        }
    }
    operand{
      name: <Zdn>.<T>
      typ: AC_ARNG
      elems:
        element{
          encodedIn: Zdn
          textExp: Is the name of the first source and destination scalable vector register, encoded in the "Zdn" field.
          symbol: <Zdn>
        }
        element{
          encodedIn: size
          textExp: size   <T>
          00      B
          01      H
          10      S
          11      D
          symbol: <T>
        }
    }
  parsed: true
--- Parsed Data ---

There are currently 38 unresolved instructions in
2290 instructions, they are all operands with optional <pattern>.
For example
https://developer.arm.com/documentation/111108/2025-12/SVE-Instructions/UQDECB--Unsigned-saturating-decrement-scalar-by-multiple-of-8-bit-predicate-constraint-element-count-?lang=en.
Should we split them into multiple different instructions?

This CL also adds a nice printer to print out the processed data.

Change-Id: Idb71499388a820108995c30ed43cc1a3f635d1e1
Reviewed-on: https://go-review.googlesource.com/c/arch/+/742461
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>