runtime: Factor out handling a single alias entry
runtime: If creating one alias fails, move on to the next one
If we need aliases for (for example) libbz2.so.1.0 and libOSMesa.so.8, and creating the alias symlink for libbz2.so.1.0 fails, there's no reason not to try to set up libOSMesa.so.8.
runtime: Briefly document RuntimeArchitecture fields
runtime: Expand logging for aliases
Not many libraries have aliases, and those that do are unusual and relatively likely to go wrong, so it's worth being a little more verbose here.
runtime: Cope with OSs where an alias is used as the canonical SONAME
The upstream SONAME of the reference libbz2 library is libbz2.so.1.0, but Fedora and its derivatives patch the build system to change the SONAME to libbz2.so.1. In Debian (and therefore the Steam Runtime) we provide libbz2.so.1 as an alias for the canonical library name, but in Fedora, libbz2.so.1 is the canonical library name (and there is no libbz2.so.1.0 symlink).
We do not normally need a host copy of libbz2 at all, because graphics drivers do not normally depend on it. but nvidia-vaapi-driver pulls it in via GStreamer and elfutils libdw.
When we set up the container, in the common case where we do not need to use the host libbz2.so.1.0, we make sure to create a symlink libbz2.so.1 in /overrides/lib/TUPLE/aliases, pointing to the runtime's driver. Similarly, if we use a newer host copy of libbz2.so.1.0 as a dependency of a graphics driver, we would create a symlink libbz2.so.1 pointing to that (via /overrides/lib/TUPLE/libbz2.so.1.0).
The case that we did not deal correctly with until now is that the graphics driver dependencies on the host include libbz2.so.1, with its SONAME set accordingly. If that happens, then we need to create a symlink that is the reverse of what we would usually do, with libbz2.so.1.0 pointing to the host's libbz2.so.1.
Seems to work fine on Fedora 38 where I could previously reproduce the lower-level symptoms of the issue.