Distinguish more clearly between wait status and exit status

• subprocess test: Check wait status correctly

  Confusingly, g_spawn_check_exit_status() takes a wait status, not an exit status, so passing g_subprocess_get_exit_status() to it is incorrect (although both encodings happen to use 0 to encode success and a nonzero value to encode failure, so in practice this probably had the desired effect).

• Distinguish more clearly between wait status and exit status

  On Unix platforms, wait() and friends yield an integer that encodes how the process exited. Confusingly, this is usually not the same as the integer passed to exit() or returned from main(): conceptually it's an integer encoding of this tagged union:

    enum { EXITED, SIGNALLED, ... } tag;
    union {
        int exit_status;         /* if EXITED */
        struct {
            int terminating_signal;
            bool core_dumped;
        } terminating_signal;    /* if SIGNALLED */
        ...
    } detail;

  Meanwhile, on Windows, wait statuses and exit statuses are interchangeable.

  I find that it's clearer what is going on if we are consistent about referring to the result of wait() as a "wait status", and the value passed to exit() as an "exit status".

  GSubprocess already gets this right: g_subprocess_get_status() returns the wait status, while g_subprocess_get_exit_status() genuinely returns the exit status. However, the GSpawn family of APIs has tended to conflate the two.

  Confusingly, g_spawn_check_exit_status() has always checked a wait status, and it would not be correct to pass an exit status to it; so let's deprecate it in favour of g_spawn_check_wait_status(), which does the same thing that g_spawn_check_exit_status() always did. Code that needs backwards-compatibility with older GLib can use:

    #if !GLIB_CHECK_VERSION(2, 69, 0)
    #define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
    #endif

• spawn: Clarify the most common non-exit reason for process termination

  A reader might think "how would a process terminate without an exit status?", or equivalently, "what harm would it do if I assume every termination has an exit status?" without this reminder that termination with a signal is also reasonably common.