pressure-vessel: Consolidate capsule-capture-libs calls

Repeatedly launching small tools like capsule-capture-libs can be slow, particularly when running pressure-vessel under an emulator like FEX-Emu (#81 (closed)) which needs to instrument each executable launch and therefore has a significant per-process overhead.

We already combined a lot of the capsule-capture-libs calls in !217 (merged), but we can still do better. Ideally, we would only run capsule-capture-libs once per destination directory. There are several tricks we can use to make this happen:

• If a driver is specified by SONAME (like the NVIDIA proprietary Vulkan driver), we should be able to bundle it into the same capsule-capture-libs invocation that captures dependencies

• If a driver is specified by SONAME, we currently use separate capsule-capture-libs expressions for the driver itself and its dependencies, but we don't actually need to do that: we can combine them

• If a driver is specified by relative or absolute path in a manifest (like Mesa Vulkan drivers) or is directly searched for in an relative or absolute path (like DRI, VA-API and VDPAU drivers), then there are two possibilities:

  1. If there are filename collisions or we need to force a search order, then we are capturing drivers into numbered subdirectories; we have to use one capsule-capture-libs invocation per numbered subdirectory, unless we change capsule-capture-libs, which I'm considering to be out-of-scope for now
  2. If there are no collisions (which is the common case in real life), then we should be able to bundle capture of each driver type (DRI, VA-API, etc.) into a single capture-capture-libs invocation

• If two or more drivers are actually the same file, via symlinks or hard-links (like the Mesa "megadriver" setup, in which all the Gallium DRI drivers are one big library with multiple entry points, and all the non-Gallium DRI drivers are another big library) then we only need to walk their dependency tree once.

• If two or more drivers are actually the same file, via symlinks or hard-links, then ideally we would only need to capture one of them, and could just duplicate its symlink for the rest.

While working on #81 (closed), I'm spending some time refactoring this. This should be a speed-up for everyone, but particularly for systems where process startup is expensive.