RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph

[Quan Anh Mai]

Hi,

Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:

- Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
- `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
- For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
- `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.

In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - Disambiguate Node::adr_type

Changes: https://git.openjdk.org/jdk/pull/28570/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372779
  Stats: 629 lines in 36 files changed: 403 ins; 72 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/28570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28570/head:pull/28570

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