add error-catching wrapper around calls to toolrunner

[nickfyson]

This PR adds a wrapper around specific exec.exec calls that are known to sometimes fail in specific ways, and captures both the exit code and stdout/err in order to match against a pre-defined list of conditions. Matching can be either by an exit code that the codeql-cli uses to indicate a specific condition, or by regex that matches against either stdout or stderr. When a match is found the wrapper throws a custom error message, which can be used to give snippets of documentation to users.

In this initial PR there is just a single matcher, intended to catch cases where no source code was seen during the build.

You can see the matchers in action in the extra (deliberately failing) integration tests here...
https://github.com/github/codeql-action/actions/runs/243679881

The testing story for this behaviour isn't entirely complete – ideally we would have integration tests like those above that deliberately trigger the errors in question and check they are caught as expected. Perhaps this could be achieved by some additional wrapper to test the wrapper, but that's all getting a little bit inception. I don't think there's a way to run to 'expect' a job to fail, but obviously that would be ideal.

Closes https://github.com/github/code-scanning/issues/1559

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.

[alexrford]

LGTM - I'm wondering now in review if it might be clearer to define ErrorMatcher as:

interface ErrorMatcher {
  returnCode?: number;
  outputRegex?: RegExp;
  message: string;
}

rather than as a tuple, but I don't think it's a big deal in the context of how we're using the matchers.

[robertbrignull]

A fair number of comments but all of them minor, so generally looks good to me. Nothing major that I think will cause problems with this approach.

[robertbrignull]

Had another quick look at the fixes and LGTM

Unfortunately looks like there are some conflicts from the merge of #181, but you may hopefully be able to just run npm run lint-fix, or maybe you'll need to fix conflicts manually first.

[robertbrignull]

Had another quick look at the fixes and LGTM

Unfortunately looks like there are some conflicts from the merge of #181, but you may hopefully be able to just run npm run lint-fix, or maybe you'll need to fix conflicts manually first.