RFR: 8371581: C2: PhaseCCP should reach fixpoint by revisiting deeply-Value-d nodes

[Aleksey Shipilev]

I started this as investigation into one rare/intermittent CTW failure that I get with [JDK-8360557](https://bugs.openjdk.org/browse/JDK-8360557). The bug seems to reproduce on a very specific JAR with a very specific random seed, so no easy regression test.

At this point I believe we found that PhaseCCP does not reach the fix point for a peculiar reason: `LoadN` that looks deeply into the graph is not revisited and thus misses the chance to update its type. There is an exception for loads in `verify_Value_for`, but it seems to only apply to constants, and does not apply to `LoadN` in question. Revisiting `LoadN` shows that updating the types downstream performs type widenings (= current types are too narrow), which AFAICS says that this unsound analysis can lead to miscompilation. See more debugging breadcrumbs in the bug.

It looks like we can reach the fixpoint by recording the nodes we need to revisit and doing another CCP round. This also makes CCP verification stricter: we effectively move 2 exceptional cases recorded in `verify_Value_for` into the analysis itself.

Testing shows there are no ill effects on correctness doing this. But I would appreciate someone more savvy in this code to sanity check all of this.

Additional testing:
 - [x] Linux x86_64 server fastdebug, CTW reproducer no longer fails
 - [x] Linux x86_64 server fastdebug, `all` tests pass
 - [x] Linux x86_64 server fastdebug, Maven Central CTW passes (!)

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/28288/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28288&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371581
  Stats: 71 lines in 2 files changed: 43 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/28288.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28288/head:pull/28288

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