CLI tools: unblock and unignore signals during startup

• Consistently unblock and unignore signals during CLI tool startup

  As with s-r-launcher-service, Steam or a game could run these tools in an arbitrary environment, with necessary signals either blocked (sigprocmask() or similar), or ignored (sigaction() with action SIG_IGN, or similar). Both of these are inherited across fork() and execve() by default.

  s-r-system-info and s-r-check-compatibility do not need this change: they already called _srt_unblock_signals(), which unblocks all signals, and unignores selected signals that have been a practical problem in the past.

  pv-try-setlocale does not need this change: in practice it only gets run by pv-adverb, so it inherits pv-adverb's fix for this.

  helpers/ do not need this change: they get called with _srt_child_setup_unblock_signals() and inherit its fix for this.

  tests/ do not need this change: Meson should run them in a sensible environment.

  steamrt/tasks#354

• utils: Clarify when _srt_child_setup_unblock_signals() can be called

• utils: Log a warning if we reset a custom signal handler

  When our executables get run via execve(), any custom signal handlers get reset to SIG_DFL by the kernel: nothing else would make sense, because the pointer to a custom signal handler would no longer be valid in the new executable's address space. As a result, we start up with all signals set to either SIG_IGN or SIG_DFL.

  _srt_unblock_signals() is meant to be called sufficiently early that it will not reset any custom signal handlers, because there should not yet be any. Log a warning if that assumption is broken.

• utils: Unignore all signals, not just the ones Steam historically altered

  To get from an unknown execution environment into a known state, it's more robust if we reset all signals, not just a few.

• Fix error reporting for pthread_sigmask()

  Unlike most POSIX functions, instead of returning -1 and setting errno on error, pthread_sigmask() returns a positive errno-like value on error.

• pv-adverb, launcher-service: Use _srt_child_setup_unblock_signals

  This avoids some duplication. It does mean that we can't check for failures, but it's not as if we can really do anything useful about any error from pthread_sigmask() anyway.

  The only errors documented for pthread_sigmask() are EFAULT (a programming error) and EINVAL (either a programming error, or use of a signal-set size not supported by the kernel). If we were going to get EINVAL, we would also have had the same error during program startup, when we called _srt_unblock_signals(), which does report errors.