RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

[Fei Gao]

`IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.

This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).

After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.

Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

-------------

Commit messages:
 - 8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

Changes: https://git.openjdk.org/jdk/pull/22862/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22862&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341611
  Stats: 8742 lines in 15 files changed: 8373 ins; 247 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/22862.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22862/head:pull/22862

PR: https://git.openjdk.org/jdk/pull/22862