arm, arm64, i386: tweak hard-coded load addresses for PIE binaries

[kib]

Summary

They are used when ASLR is not applied.
The need for adjusting is due to rtld direct exec mode puts ld-elf.so.1
at the PIE load address, and this address must not conflict with the
default linker' load address for non-PIE binaries.  Otherwise rtld in
direct mode cannot activate image.  Example of implicit failure is ldd(1)
refusing to run.

Reported by:    kp

i386: move hard-coded load address for PIE below default linker base

both for i386 native and compat32 amd64.  We know the ld-elf.so.1 size
in advance, it fits there.  Trying to push it up after the end of a
binary cannot work reliably and eventually fail for large binaries.

[markmi_dsl-only.net]

What of the i386 failure example that https://lists.freebsd.org/archives/dev-commits-src-main/2022-October/010362.html reports:

[ -z "ldd " ] || [ -z "`ldd  install/q2map.i386 2>&1 1>/dev/null | tee /dev/stderr`" ] || { rm -f install/q2map.i386; exit 1; }
ld-elf.so.1: install/q2map.i386: mmap of entire address space failed: Cannot allocate memory
install/q2map.i386: exit status 1
gmake[1]: *** [Makefile:461: install/q2map.i386] Error 1
gmake[1]: *** Waiting for unfinished jobs....
[ -z "ldd " ] || [ -z "`ldd  install/qdata3.i386 2>&1 1>/dev/null | tee /dev/stderr`" ] || { rm -f install/qdata3.i386; exit 1; }
ld-elf.so.1: install/qdata3.i386: mmap of entire address space failed: Cannot allocate memory
install/qdata3.i386: exit status 1

as shown in the build server log: http://beefy17.nyi.freebsd.org/data/main-i386-default/pce69f38a72dd_s9c95013905/logs/netradiant-20150621_4.log ?

Does 32-bit powerpc ldd on powerpc64 variants that support 32-bit powerpc code have the issue for chroot/jail use of 32-bit worlds as well? (I no longer have access to powerpc/power family members and so can not test.)

[kp]

This patch also allows our builds to complete.

[kib]

Handle i386