Provide a mechanism to run commands outside the container

• launch-client: Deprecate --dbus-address and --socket

  These options correspond to deprecated ways to make launcher-service listen for connections.

• launcher-service: Use a GPtrArray for bus names

  GPtrArray is easier to use correctly than a realloc'd GStrv whose size needs to be kept track of separately, particularly if we want to listen on more bus names.

• launcher-service: Move original environment and cwd from SrtPortalListener

  This information was stored in SrtPortalListener, but not for any particularly good reason, because nothing in that module actually used it. Move it to the module that makes use of that information.

  While doing so, rename original_environ to child_environ, since we are likely to start making edits to the original environment for !560 (merged).

• runtime: Add a function to unset the LD_LIBRARY_PATH Steam Runtime

  steam-runtime-launcher-service needs to be run under some version of the Steam Runtime to guarantee that its dependencies are available, so if we want to be able to run user processes in an environment more closely resembling the one Steam was started from, we'll need this.

• launcher-service: Add a --no-replace option for completeness

  We might need this if we want to make other options imply --replace as a default, and in general it's usually good for boolean options to be in pairs.

• launcher-service: Add an --alongside-steam option

  This allows Steam to provide a process-launching service that is outside the container runtime (but possibly inside a larger sandbox like Flatpak or Snap), allowing game processes to run tools such as mango_intel_stats that cannot usefully be run inside the container (steamrt/tasks#293, #107 (closed)).

  The intended use is that Steam will run this, with the PATH and LD_LIBRARY_PATH of the Steam Runtime 1 'scout' environment in effect:

    steam-runtime-launcher-service --alongside-steam

  Some defaults change when this option is in use, to be more suitable for this use-case.

  Steam can optionally set environment variable SRT_LAUNCHER_SERVICE_ALONGSIDE_STEAM to com.steampowered.PressureVessel.LaunchAlongsideSteam in the environment used to launch games, as a way to signal that this mechanism is available.

  If desired, Steam can wait for the launcher service to be ready by passing a pipe to it as its standard output (fd 1) or as a higher fd referenced by the --info-fd option, and then reading from that pipe until end-of-file is reached. If it does this before launching any apps or games, then apps and games can safely assume that the launcher service is ready for immediate use.

  Alternatively, Steam can let the launcher service start asynchronously, by passing /dev/null as its standard output. If this is done, an app or game that starts up very quickly after Steam is launched might find that steam-runtime-launch-client --alongside-steam -- ... does not work until some time has passed.

  To the extent that it's possible, launched processes get the same host execution environment as the top-level process of Steam itself (the bin_steam.sh script); this is similar to what happens for non-Steam app shortcuts. They can re-enter the Steam Runtime 1 'scout' environment, if desired, by running ~/.steam/root/ubuntu12_32/steam-runtime/run.sh.

• tests: Test various ways to start launcher-service

• launch-client: Add the ability to ask to run outside pressure-vessel

  This uses IPC from inside the per-app/game container to run commands outside, and is very similar to flatpak-spawn --host. The purpose of this feature is to let diagnostic tools like MangoHUD run a command outside the container even though the actual game is running inside. MangoHUD's initial use-case for this is to run mango_intel_stats to get Intel GPU statistics. It could also be useful as a way to run parts of the Steam client, or other client-level features like SteamVR, inside a container, while still allowing them to run (possibly privileged) commands on the host system.

  This is the reverse of how we have used launcher-service/launch-client in the past, which was to use IPC from outside the per-app/game container to run debugging commands inside.

  steamrt/tasks#293, #107 (closed)

• tests: Test various ways to run launch-client