pv-runtime: Don't rewrite /nix/store/... to /run/host/nix/store/...

• runtime: Comment why the /app special case exists

• pv-runtime: Don't rewrite /nix/store/... to /run/host/nix/store/...

  We must expose /nix in the sandbox as /nix, not /run/host/nix, because hard-coding paths below /nix is ubiquitous on NixOS. There's already a special case in wrap.c to mount /nix read-only.

  This resolves a regression that occurred when we switched to a runtime structure that relies on PRESSURE_VESSEL_COPY_RUNTIME.

  Resolves: https://github.com/ValveSoftware/steam-runtime/issues/431

• runtime: Assume /etc is visible in the provider namespace

  If the realpath() of an OS file is below /etc, each of our code paths ends up with it visible below /run/host/etc, /run/parent/etc or /run/gfx/etc, as appropriate.

• runtime: Adjust fallback behaviour when taking files from provider

  Previously, we assumed that if OS files on the provider are in a location that is not /usr or a related directory, for example if the OS has /lib/ld-linux.so.2 -> /some/odd/path/i386/ld.so, then they will appear below the same path_in_container_ns as /usr, for example /run/host/some/odd/path/i386/ld.so. However, nothing sets this up for directories other than /usr, /lib*, /bin, /sbin and /etc, so it's a bad assumption.

  A previous commit handled /etc by redirecting it to /run/host/etc, /run/parent/etc or /run/gfx/etc as appropriate, so we don't need to worry about that here.

  For the rest, assume that if they appear in the container at all, they'll appear at a path that matches their location in the provider. For the common case where provider = host, which is the only one where we really need to support non-FHS layouts, this means that users can work around lack of explicit support for a particular non-FHS directory with something like PRESSURE_VESSEL_FILESYSTEMS_RO=/some/odd/path.

  In particular, if we didn't have explicit support for /nix, NixOS users would have been able to use that workaround to get it mounted.