Give a little more information in pyre check crash messages

Summary:
I spent a long while debugging issues with torchx github CI whose root
cause was that the glibc used in CI was too old.

A better error message would have helped in two ways:
- The current message just states an exit code, and then the client
  itself exits nonzero so you get another message from bash about a different
  nonzero exit code. This is confusing, especially becauese the glibc failure
  leads to exit code 1, which is what the *frontend* exits in a normal
  flow where there are type errors. You have to squint to see the difference,
  or else already know exactly what happened. The updated message clearly
  states that the first exit code we are logging is the *backend* exit code,
  which makes it obvious for anyone on our oncall what happened.
- The first step of debugging is very likely going to be to find a way of
  directly invoking the binary to see more information about the failure,
  which is needed because I think sometimes bash gives extra information about
  failures that isn't actually part of stderr. It's true the binary location
  is in the logs already if running with `-n`, but the flow will be faster,
  especially for anyone who has done this debugging fewer times, if the error
  message gives the binary location directly.

Reviewed By: rchen152

Differential Revision: D67035442

fbshipit-source-id: 47331a7bc4bd217e87f55b505f6ecf450457cc2a

client/commands/check.py

@@ -218,7 +218,8 @@ def _run_check_command(command: Sequence[str]) -> CheckResult:
 
             else:
                 LOG.error(
-                    f"Check command exited with non-zero return code: {return_code}."
+                    f"The backend check command exited with non-zero return code: {return_code}. "
+                    f"This likely indicates a problem with the Pyre binary at `{command[0]}`."
                 )
                 return CheckResult(commands.ExitCode.FAILURE, [])