Capturing the libudev.so.0 soname could lead to a missing libudev.so.1

Since !498 (merged), we now try to explicitly collect libudev.so.0 and libudev.so.1 from the host system.

There has been a couple of users reports where this caused an apparent regression https://github.com/ValveSoftware/steam-runtime/issues/533.

It turned out that this is due to an unexpected symlink between libudev.so.0 and libudev.so.1. Even if that symlink should not be present in the first place on the host system, in theory it should not prevent the container to be correctly set up.

I tried to recreate the environment that triggered this issue:

❯ ls -la /usr/lib/libteest*
lrwxrwxrwx 1 root root     17 Sep 26 16:20 /usr/lib/libteest.so -> libteest.so.1.7.4
lrwxrwxrwx 1 root root     22 Sep 26 16:20 /usr/lib/libteest.so.0 -> /usr/lib/libteest.so.1
lrwxrwxrwx 1 root root     17 Sep 26 16:20 /usr/lib/libteest.so.1 -> libteest.so.1.7.4
-rwxr-xr-x 1 root root 182488 Sep 26 16:19 /usr/lib/libteest.so.1.7.4

However I was unable to reproduce it:

❯ x86_64-linux-gnu-capsule-capture-libs --container /tmp/b --provider / --dest /tmp/b "if-exists:if-same-abi:soname:libteest.so.0" "if-exists:if-same-abi:soname:libteest.so.1"

❯ ls -la /tmp/b/libteest*
lrwxrwxrwx 1 ryuzaki ryuzaki 26 Sep 26 16:24 /tmp/b/libteest.so.0 -> /usr/lib/libteest.so.1.7.4
lrwxrwxrwx 1 ryuzaki ryuzaki 26 Sep 26 16:24 /tmp/b/libteest.so.1 -> /usr/lib/libteest.so.1.7.4

As @smcv mentioned, in the short term we should probably just remove libudev.so.0 from collect_core_libraries_patterns() -> !500 (merged)

After that, we should investigate what was the actual problem that caused the libudev.so.1 to be missing.