capture-libs: Treat unversioned libraries as in indeterminate order

• capture-libs: Clarify by introducing more temporaries

• capture-libs: Factor out library_cmp_by_name()

• capture-libs: Treat unversioned libraries as in indeterminate order

  On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most shared libraries.

  However, on Fedora 30 it is a symlink to a versioned name like libgcc_s-9-20190827.so.1. The name used in Fedora happens to be less than libgcc_s.so.1 in strverscmp() order, causing capsule-capture-libs to prefer the Debian/Manjaro libgcc_s.so.1, even if the container is older. This can cause problems if an old Debian-derived container like the Steam Runtime is used on a newer Fedora host, with host graphics drivers imported by using capsule-capture-libs: the container's libgcc_s.so.1 does not satisfy the versioned symbol requirements of the graphics driver, causing loading to fail.

  Treat a regular file libgcc_s.so.1 as indeterminate order (or "equal"), so that we fall back to the default behaviour, which is currently to take the host version of the library in the case of a tie.

  This is a stopgap solution: ideally we would consider the versioned symbols exported by both libraries, and take whichever one has a superset of the version definitions exported by the other, if there is a strict superset in either direction (in the case of libgcc, in fact there is).