Add functionality for parsing Action inputs from a workflow file

[henrymercer]

In order to upload SARIF files for code scanning runs where the init step failed, we need to be able to handle the case where the analyze Action did not run. In this case, the post-analyze step will not be run, and therefore we don't know the inputs to analyze. (In particular, we care about category, upload, and checkout_path.)

This PR implements some functionality to make a best effort attempt to work out the value of an input to an Action given the workflow file and information that's available to the init step like matrix variables. I recommend reviewing the first commit separately since it separates out workflow-related code into a separate file workflow.ts.

Merge / deployment checklist

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

[aeisenberg]

OK. This will now throw if we can't determine what the actual input value is. I don't actually see where getting the category is being used. Is that coming in a later PR? We should make sure that the action doesn't fail if it can't find the category (most likely, the action will already have failed for some other reason, so we need to at least make sure that this failure doesn't hide the original failure).

[henrymercer]

This functionality is just for #1393 — ideally we'd minimise the number of places where we need to do this hacky parsing of the workflow. We wrap it in a try-catch block there to avoid hiding the original failure as you mention. I think the tryOrThrow names should make it fairly obvious that these functions should generally be surrounded by try-catch blocks — is there anything else we should do to avoid future consumers creating bugs?

[aeisenberg]

I think that all makes sense. I'll review #1393 later today. Maybe just adding a comment to the function suggesting that it should be wrapped in a try-catch.

[aeisenberg]

LGTM. Optionally, add a comment to the tryOrThrow... functions to suggest wrapping in try-catch.