Refactoring in preparation for Flatpak support

This follows on from !207 (merged). It should be basically ready for review; as with all my big refactoring branches, commit-by-commit is almost certainly going to be the easiest way.

I think this works for the non-Flatpak case, but the size of some of the commits is a bit scary, so I want to get a new beta out (with your logging changes and maybe !207 (merged), but without this) before we try merging this.

---

• pressure-vessel: Use a temporary FlatpakBwrap for adverb argv

  This makes it clearer where the various arguments are going.

• pressure-vessel: Make trailing arguments giving command to run clearer

  Only use the name wrapped_command when it is genuinely a command that we are wrapping. Use a new temporary FlatpakBwrap structure, launcher_argv, for the case where it just contains arguments for the launcher.

• pressure-vessel: Stop worrying about whether argv[1][0] is "-"

  The reason we originally did this is that older versions of bwrap didn't support the GNU-style "--" argument separator, used to disambiguate between non-option arguments and strangely-named executables that happened to start with a minus.

  However, we now wrap our user-controlled "payload" command with pressure-vessel-adverb(1) in all cases, which means we don't need this. bwrap's first non-option argument is the absolute path to pressure-vessel-adverb, which definitely does not start with "-" and so cannot be confused with an option; and all of our own commands, notably pressure-vessel-adverb, use GOptionContext and therefore support the "--" option-separator correctly.

• pressure-vessel: Use a different name for final argv/envp/etc.

  We're using FlatpakBwrap as a convenient way to collect up a set of argv, envp and inherited file descriptors, but it isn't actually a bwrap command in all cases. Use a less misleading name.

• pressure-vessel: Use a temporary FlatpakBwrap for X11, fonts, etc.

  These are more similar than they are different. In a subsequent commit we'll change how this works, and re-indenting it here will make that more reviewable.

• pressure-vessel: If verbose, make sure -launcher is verbose too

• pressure-vessel: Separate argv for what we'll run in the container

  This makes the boundary between things inside the container and things outside the container clearer, which will be valuable when we stop always invoking bwrap directly ourselves.

• pressure-vessel: Separate environment variables needed to run pv-launch

  The environment variables we have built up in bwrap are appropriate for the container itself, but inappropriate for the environment in which we run pressure-vessel-launch to ask Flatpak on the host to run bwrap. Keep them more carefully separate.

• pressure-vessel: Move environment variables into new PvEnviron object

  This keeps track of environment variables' values and their locked status in one place. We build it up over time, and then serialize it into final_argv->envp.

  In particular, this is a step towards no longer storing anything in the variable named bwrap except for bubblewrap options, which will be a necessary piece of refactoring when we move to launching the game as a Flatpak sub-sandbox, without ever invoking bubblewrap ourselves.