Avoid analyzing OSR guards as virtual guards in versioner

[jdmpapin]

It used to be that a standalone OSR guard could not target a cold call. However, virtual guards target cold calls even when they are merged with OSR guards. Recently, VP learned to remove the virtual part of a virtual guard despite any merged guards (3d1fec9, #6762). The merged HCR or OSR guard is promoted to a standalone HCR or OSR guard, and any standalone OSR guard produced in this way does target a cold call.

It was possible for such an OSR guard to be confused for a virtual guard, and therefore for loop versioner to try to version it as though it were a virtual guard, resulting in an assertion failure:

guardOkForExpr: should not intern OSR guard ...

This happened only very rarely because the OSR guard does not use VFT test or method test, so in order to confuse it for a virtual guard, the OSR guard's BCI must correspond to that of the cold call in the same way as it would for a virtual guard. An OSR guard's inlined call site index is copied from the BBStart on the taken side, which usually identifies the caller rather than the callee, but the latter is required in order to provoke the bug.

Additionally, buildConditionalTree() had a path that excluded HCR guard but not direct method guard. It shouldn't matter, since neither should be considered an invariant conditional there, but that path now also excludes direct method guard for consistency.

---

There is an additional commit to prevent this confusion in another way:

• Set inlined call site index to -1 for all OSR guards

---

Fixes eclipse-openj9/openj9#16115

[vijaysun-omr]

Jenkins build all

[jdmpapin]

The PPC64LE Linux failure is #6571. The RISC-V Linux failure is #6704.

On z/OS, git fetch failed:

16:22:17  stdout: FOTS1370 Host key verification failed.
16:22:17  fatal: Could not read from remote repository.

Jenkins build zos

[vijaysun-omr]

Merging since both failures are known ones and reviews are done.