Stop special-casing unevaluated aconst in Power and ARM linkage

[jdmpapin]

Instead, simply evaluate it like we do for other arguments.

These were the only two places where a TR_RamMethodSequence relocation could be generated for a method other than the outermost method, which is not expected. All remaining uses of TR_RamMethodSequence are for compiledMethodSymbol, which always represents the outermost method.

Fixes eclipse-openj9/openj9#17889

[0xdaryl]

@zl-wang : This seems reasonable to me. Are you ok with the Power changes?

[dsouzai]

Is it worth only preventing special-casing for relocatable compilations?

[jdmpapin]

I didn't see any changes in the generated code outside of AOT, so I don't think we need to preserve the special case there

OTOH, in AOT I did see some changes to the (PPC64) sequence generated for aconst nodes in this position

• aconst NULL is improved: li <reg>, 0 instead of a 5-instruction sequence
• for other aconst nodes we load from a data snippet, resulting in a slightly worse sequence

I don't think we should be concerned about the use of the data snippet as it pertains to this PR. This change appears to affect only AOT, and it's highly unusual for non-null aconst nodes to occur as a call argument

We might still want to try to improve the sequence generated for aconst in AOT, but mainly for other reasons. By far the main use of non-null aconst is for profiled guards, which are not changing in this PR

[dsouzai]

jenkins build aix,plinux,arm

[dsouzai]

Jenkins build aix,plinux,arm

[zl-wang]

Looks good ...