[release-1.8] Consistently use RUNPATH in our libraries

[staticfloat]

When loading dependencies on Linux, we can either use RPATH or
RUNPATH as a list of relative paths to search for libraries. The
difference, for our purposes, mainly lies within how this interacts with
LD_LIBRARY_PATH: RPATH is searched first, then LD_LIBRARY_PATH,
then RUNPATH. So by using RUNPATH here, we are explicitly allowing
ourselves to be overridden by LD_LIBRARY_PATH. This is fine, as long
as we are consistent across our entire library line, however in the
v1.8.0 release, there was an inconsistency, reported in [0].

The inconsistency occured because of the following confluence of factors:

• Ancient ld builds (such as the one used in our build environment)
  do not default to using RUNPATH, but instead use RPATH.
• patchelf, when it rewrites the RPATH, will default to using
  RUNPATH instead.
• We were only using patchelf on libjulia-internal, not on
  libjulia-codegen, which was newly added in v1.8.

These three factors together caused us to ship a binary with RUNPATH
in libjulia-internal, but RPATH in libjulia-codegen, which caused
loading to fail in [0] due to first libjulia-internal being loaded,
(which brought in the external libstdc++), then libjulia-codegen
failed to load (because it found an incompatible libstdc++), causing
the mysterious compiler error.

This PR fixes this twofold; first, when building the libraries in the
first place, we pass --enable-new-dtags to the linker to encourage it
to use runpath when possible. This removes the possibility for a
missing patchelf invocation to break things in this way. Second, we
apply patchelf properly to libjulia-codegen as well.

[0] #46409