RFR: 8296318: use-def assert: special case undetected loops nested in infinite loops

[Emanuel Peter]

`PhaseCFG::verify` checks that the nodes scheduled into the blocks have "use-after-def".
https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/block.cpp#L1376

As long as the control flow has no loops, this should always hold.
We make sure to not check the assert if the block-head is a `LoopNode`, and the use `n` is a `Phi`, since we may have inputs from the backedge, which would be "use-before-def" in the block-scheduling order, but that is to be expected.
https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/block.cpp#L1364

**Problem**
This assumes that all loops are properly detected, if a loop was not detected the block-head may only be a `RegionNode`, and the assert can fail (see regression test). Why are not all loops detected?
During `PhaseIdealLoop::build_loop_tree`, we detect all loops, but not always attach infinite loops with their sub-loops to the loop tree, and then the loop-head `Regions` are not converted to `LoopNodes` in `PhaseIdealLoop::beautify_loops`.
This behaviour is expected, see also https://github.com/openjdk/jdk/pull/11473.
Thus, the assert fires, but it should not.

**Solution**
Add special casing to assert: also accept if the `Region` is in an infinite subgraph, and we are looking at a `Phi` as use (the def could be values from the backedge).

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

Commit messages:
 - made assert more precise
 - 8296318: use-def assert: special case undetected loops nested in infinite loops

Changes: https://git.openjdk.org/jdk/pull/11642/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11642&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296318
  Stats: 134 lines in 5 files changed: 109 ins; 23 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11642.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11642/head:pull/11642

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