fix: error on R_X86_64_32/32S relocations in shared objects

[deepakshirkem]

R_X86_64_32 and R_X86_64_32S cannot be used when making a shared object because the dynamic linker has no way to patch 32-bit absolute relocations at runtime. Wild was silently emitting R_X86_64_64 instead of erroring, producing a broken shared object.

Add an early check in apply_relocation to error when these relocation types are encountered while building a shared object, matching the behavior of GNU ld and lld.

Fixes #2074

[davidlattimore]

Could be good to enable ld (and possibly lld) for the test. If all linkers have "recompile with -fPIC" then you could have that as the error matcher. If you want to verify that Wild says the message below, then you could add "ExpectErrorWild" (implementing it should be pretty trivial - there's already an "ExpectWarningWild")

[deepakshirkem]

@davidlattimore, One question: should we extend this PR to also report an error for sub-pointer-size absolute relocations on other 64-bit architectures such as AArch64, RISC-V64, PPC64, and LoongArch64?
They seem to have the same fundamental issue with ByteSize(4) absolute relocations in shared objects.
I could either implement a generic check based on the architecture trait, or add explicit relocation-type checks in each architecture file, similar to what we did for x86_64. Which approach do you think would be preferable?

[davidlattimore]

That'd be great if you can make the check generic. It could also be good to look to see if the check can be done in the layout phase rather than the write phase. That said, it's OK if it stays in the write phase.