Don't symlink all of /usr/${gnu_tuple}/lib, but be more selective
Previously, we made all of /usr/${gnu_tuple}/lib a symbolic link to /usr/lib/${multiarch_tuple}, so that when Exherbo ld.so or libraries look for architecture-specific content (in particular the dynamic linker), they find it in the Debian-style architecture-specific lib directory.
However, this causes problems in the presence of RPATHs. Some Exherbo libraries have a RPATH header pointing to /usr/${gnu_tuple}/lib; because RPATH is higher-precedence than LD_LIBRARY_PATH, this caused the runtime linker to load dependency libraries from the Steam Runtime's /usr/lib/${multiarch_tuple}, even if we had imported a newer version from the Exherbo host system into /overrides/lib/${multiarch_tuple} which we expected to be used instead.
Because Exherbo's glibc expects to load gconv plugins from /usr/${gnu_tuple}/lib/gconv, if Exherbo's glibc is newer than the runtime's (which in practice will often be true), we need to be able to bind-mount the gconv plugin directory from the host system; so we also create a mount point for that.
Thanks to @mawww on Github for testing this arrangement.
To be cherry-picked into all supported branches, but we only need to review this once.