Fix handling of Vulkan manifests in /etc (and also error handling)

• resolve-in-sysroot: Produce better diagnostics on failure to open

  If we pass in SRT_RESOLVE_FLAGS_READABLE or SRT_RESOLVE_FLAGS_DIRECTORY, and something goes wrong while we are opening the file, then the best diagnostics libglnx can give us will be something like "openat(/proc/self/fd/21): ", which is not very informative.

  Adding current_path turns this into something more like "Unable to open "foo/bar": openat(/proc/self/fd/21): ", which gives us more hope of figuring it out.

  I originally suspected this was the error path being hit in https://github.com/ValveSoftware/steam-runtime/issues/366, but now I think it probably isn't.

• Add test coverage for the code path touched in the previous commit

• runtime: Make pv_runtime_take_from_provider failure a bit clearer

  Putting a prefix on the rather opaque error should make it more obvious what we were trying to do.

• runtime: Avoid "piling up" errors

  _srt_resolve_in_sysroot raises a GError, so it's a bug to set the GError again. Just put an explanatory prefix on the error we already had.

• runtime: Don't try to glnx_file_copy_at() from a magic symlink

  In the code path where we copy a file that would not otherwise be visible in the container, the copy doesn't actually work, because glnx_file_copy_at() opens regular files with O_NOFOLLOW and so refuses to read through the "magic symlink", failing with ELOOP.

  This can be reproduced by having a Vulkan ICD manifest in /etc/vulkan/icd.d/*.json whose library_path is just a SONAME. pressure-vessel tries to copy the file, and fails.

  It turns out glnx_file_copy_at() is not the right function here anyway, because it tries to fchown() the destination file to match the source file, which is going to work poorly if we are copying a file owned by root (which we often are). Just use the important part of it, which is glnx_regfile_copy_bytes().

  Resolves: https://github.com/ValveSoftware/steam-runtime/issues/366 (I think)