Fix check for whether wide relocation offsets are needed on Power

[aviansie-ben]

Previously, there was special-case code in the collectModifier method on
TR::ExternalRelocation which was trying to handle relocations whose
targets were actually the address of the TR::Instruction rather than the
binary-encoded instruction. However, this is now being handled by
TR::BeforeBinaryEncodingExternalRelocation overriding the
getUpdateLocation method. As a result, this check was calculating the
wrong update location. The apply method was using the correct update
location and thus only calculation of whether wide offsets were needed
was affected by this problem.

This issue went unnoticed for a considerable length of time since the
pseudo-random nature of the incorrect update location would almost
always result in wide offsets being used. Using wide offsets when not
needed is unnecessary, but does not cause any correctness issues.

Signed-off-by: Ben Thomas ben@benthomas.ca

[fjeremic]

The apply method was using the correct update
location and thus only calculation of whether wide offsets were needed
was affected by this problem.

This issue went unnoticed for a considerable length of time since the
pseudo-random nature of the incorrect update location would almost
always result in wide offsets being used. Using wide offsets when not
needed is unnecessary, but does not cause any correctness issues.

FYI in case you've never come across it. The JIT has a TR_Randomize option which you can use to generate random numbers and force certain "rarely taken" paths to be taken. This can provoke these types of issues by putting in randomgen code to randomly use wide offsets. See #3568 for a recent example.

[0xdaryl]

@genie-omr build all