g_test_trap_subprocess: should be able to manipulate execution environment of the subprocess

A few times I've found myself wanting to alter the execution environment of a GTest subprocess, usually by setting environment variables but sometimes in other ways. I usually end up writing a separate helper executable and running it with GSubprocessLauncher or similar instead.

Straw-man API:

g_autoptr(GTestSubprocessLauncher) launcher = g_test_subprocess_launcher_new (... some flags? ...);
g_test_subprocess_launcher_setenv ("DEBUG", "all", TRUE);
g_test_subprocess_launcher_set_argv_prefix ("dbus-run-session", "--", NULL);
g_test_subprocess_launcher_trap ();
g_test_trap_assert_failed ();
g_test_trap_assert_stderr ("*ERROR*too large*");

Or maybe the launcher could literally be a GSubprocessLauncher, or perhaps a subclass:

g_autoptr(GSubprocessLauncher) launcher = g_subprocess_launcher_new (... some flags ...);
g_subprocess_launcher_setenv ("DEBUG", "all", TRUE);
g_subprocess_launcher_set_argv_prefix ("dbus-run-session", "--", NULL);
g_test_trap_subprocess_with_launcher (NULL, 30 * G_USEC_PER_SEC);
g_test_trap_assert_failed ();
g_test_trap_assert_stderr ("*ERROR*too large*");

If it's a subclass, it could potentially even have an option to run a custom D-Bus session bus (with a private services directory, and optionally pretending to be the system bus) like GTestDBus does. This would get rid of all the singleton-lifetime and thread-safety concerns about GTestDBus (#563), by arranging for the singletons and the environment variable changes to be in a subprocess.

However, @pwithnall notes that subprocesses are quite a big hammer, and in particular make use of gdb and valgrind harder than we would like it to be, so we don't necessarily want this to be the recommended or only answer to the problem of having a private bus for tests.