Repurpose pressure-vessel-launcher as a general-purpose command-launching tool

For some debugging use-cases, we want to have a way to inject commands into a container environment, or inject commands into the process subtree managed by Steam's reaper, or some similar situation.

I think the best way to do this is to have an IPC service (analogous to flatpak-portal or sshd) inside the container/subtree/whatever, and an IPC client (analogous to flatpak-spawn or ssh) on the outside. The client connects to the service on either a private AF_UNIX socket or the D-Bus session bus, uses fd-passing to transfer stdin/stdout/stderr file descriptors to the service, and asks the service to run an arbitrary command-line on its behalf.

We already have this client/service pair, left over from pressure-vessel's "session mode": pressure-vessel-launcher is the service and pressure-vessel-launch is the client. In this branch I've renamed them to steam-runtime-launcher-service and steam-runtime-launch-client.

Because of the way Steam sets up games and compat tools, this is going to be a bit easier to achieve if the service can act like an "adverb": steam-runtime-launcher-service --socket=... -- xterm.

To accompany this, we'll need changes to Steam compat tools to make them support running a steam-runtime-launcher-service from one compat tool; and we'll also need changes to Steam itself, to make it tell the "innermost" compat tool to run steam-runtime-launcher-service.

We don't want more than one compat tool to be listening for commands, to avoid them all fighting over the same socket name; and I think we also don't want an "outer" compat tool to be responsible for setting up the steam-runtime-launcher-service, because if we did that, then the launched command would not be launched in the same environment as the actual game.

The first few commits are preparatory refactoring.

---

• Move pressure-vessel's logging setup into library code

  The names were confusingly similar, but _srt_util_set_up_logging() was actually orthogonal to pv_set_up_logging(): the former was about the disposition of the stdout and stderr fds, whereas the latter was about the GLib log handler. Rename it to make the difference clearer.

• Move pv_async_signal_safe_error into library code

• Move pv_get_current_dirs() to library code

  This requires switching it from flatpak_canonicalize_filename() to g_canonicalize_filename().

• Move pv_get_random_uuid() to library code

• launcher: Move global variables into a data structure

• launcher: Respect exit status if set programmatically

• launcher: Improve documentation

• portal-listener: Move responsibility for closing info fd into caller

• launcher: Factor out pv_launcher_server_finish_startup()

  This gives us somewhere to put actions that should happen when the listening socket or bus name is ready for use, such as starting a wrapped subcommand.

• portal-listener: Make it possible to disable the info fd completely

  The comment incorrectly said that 0 is stdout itself, but 0 is actually stdin, which would make no sense. There are now three valid options:

  • fd < 0, previously used original stdout, now disables info fd
  • fd == 1, uses the original stdout
  • fd > 1, use the specified fd

  plus one invalid argument (fd == 0, previously mistakenly used stdout even though fd 0 is stdin, now an error).

• portal-listener: Stop listening on socket when portal is exiting

  We should stop taking new requests as soon as we have made the decision that we are going to exit. For the session bus, the way we stop getting incoming requests is by releasing our bus name, but the equivalent for a custom GDBusServer is to stop listening on our AF_UNIX socket.

• launcher: Add the ability to wrap an arbitrary command

• launcher: Add test coverage for a wrapped command

• Move pressure-vessel's gdbus code generation into steam-runtime-tools

• Rename pv-launch to s-r-launch-client and move it to bin/

• Move PvPortalListener into library code

• Rename pressure-vessel-launcher to s-r-launcher-service, move to bin/