Restore ability to use a setuid bwrap

• Update comments/messages to refer to s-r-launch-client, not pv-launch

  Fixes: 3fbb5d8a "Rename pv-launch to s-r-launch-client and move it to bin/"

• Update a debug message to refer to s-r-launcher-service, not pv-launcher

  Fixes: ba4aaede "Rename pressure-vessel-launcher to s-r-launcher-service, move to bin/"

• launch-client(1): Document --env-fd

  Fixes: b1a34381 "launch-client: Add --env-fd option"

• pv-wrap: Remove a redundant conditional

• pv-runtime: Factor out pv_runtime_get_ld_library_path()

  No functional change intended.

• SrtEnvOverlay: Rename from PvEnviron

  This isn't really an environment block, so it was always mis-named. It's really a set of instructions for how to modify an environment block by setting variables, unsetting variables, or allowing variables to be inherited.

  Moving it into library code will allow us to share it between srt-launch-client and anywhere else that needs it.

• launch-client: Use SrtEnvOverlay instead of two hash tables

• SrtEnvOverlay: Add reference-counting

• SrtEnvOverlay: Factor out and test _srt_env_overlay_apply()

• SrtEnvOverlay: Handle basic command-line parsing internally

  --clear-env, --pass-env and --pass-env-matching are still separate, because they will not always make sense.

• adverb: Add options to manipulate environment variables

  As well as being generically useful functionality for a supervisor/adverb process, this is an enabler for injecting LD_LIBRARY_PATH at a different stage in order to fix regressions with a setuid bwrap.

• pv-wrap: Remove dead code for non-subsandbox Flatpak

  We no longer support any code paths where we are in Flatpak and not using a subsandbox, so this code can go away.

  Fixes: f4f25f4b "pv-wrap: Remove support for escaping from a Flatpak container"

• SrtEnvOverlay: Add and test serializing environment in env -0 format

  This can be used as input to s-r-launch-client --env-fd, pv-adverb --env-fd, or similar interfaces like flatpak run.

• pv-wrap: Send Flatpak subsandbox environment variables via --env-fd

  This avoids exposing them among the arguments in /proc, and also results in a much shorter command-line, making ps and similar tools more useful.

• pv-wrap: Try harder to get the initial LD_LIBRARY_PATH into pv-adverb

  If bwrap is setuid root, we were previously pushing LD_LIBRARY_PATH into it via bwrap --setenv, but it turns out that doesn't actually work: the fact that bwrap is setuid means that the environment variable won't stick. The result is that pv-adverb doesn't have the host system's glibc in its library search path and can't start.

  We can avoid this problem by using ld.so(8) to invoke pv-adverb with a specified search path, and then telling pv-adverb to finish setting up the environment before it runs ldconfig(8) to regenerate the ld.so.cache.

  Instead of second-guessing which environment variables glibc is going to filter out in setuid executables, we just serialize all of them - with --env-fd there's no longer any real reason not to.

• pv-adverb: Run ldconfig earlier

  Until we have run ldconfig, we cannot rely on tools like the detect-lib and detect-platform helpers being able to run.

• pv-adverb: Apply --env-fd, etc. to the environment used for subprocesses

  If we're running under a setuid bwrap, our original environment variables might be insufficient to run helper subprocesses. In particular, on Ubuntu, /sbin/ldconfig is a shell script which will need our LD_LIBRARY_PATH.

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