Mark GPR15 unpreserved for Helper call on z/OS

[r30shah]

On z/OS when returning from interpreter back to JIT compiled code, a branch is made through GPR15. For XPLINK, GPR15 is considered preserved register so JIT compiled code when dispatching the helper call would consider it as preserved register. In cases when we return back to JIT compiled code from interpreter, it could clobber GPR15 to branch back to JIT. This is a unique issue uncovered with synchronized virtual thread where helper call to jitMonitorEnter from JIT compiled code can return back from interpreter. Changes in this commit would mark GPR15 not preserved so it will be preserved as helper dispatch sequence.

[r30shah]

@joransiu Can I get your review on these changes ?

I was looking at the XPLINK to find out if we can use other register. Jump back happens from Interpreter where we switch to Java Stack, and I looked into private linkage and XPLINK, I can not find other register which is not preserved to use for jump. I am opening up this PR which will conservative avoid using GPR15 as preserved register. Opening up an issue to investigate other way to fix this issue but meanwhile, we can get this change in to avoid issues on z/OS.

[joransiu]

LGTM. This is a conservative fix until we can better tackle how to ensure GPR15 is preserved on the return from interpreter path.

[joransiu]

jenkins test sanity zlinux jdk21

[pshipton]

This causes failures like the following in the 31-bit build

j> 11:25:16 Assertion failed at /j9tmp/bld_105529/bld_zos_390/compiler/../omr/compiler/z/codegen/OMRMachine.cpp:2255: false
j> 11:25:16 VMState: 
j> 11:25:16 	Ran out of register candidates to free on instruction [3dbc1fb0]

[pshipton]

Reverted via #22850