Retrieve external API usage snippets using SARIF

[koesie10]

This implements the retrieval of external API usage snippets using a SARIF file.

The alternative is retrieving the usage manually given a file and a range within this file. However, this is quite hard to do and would create a separate implementation from the one already present in the CodeQL CLI.

Checklist

• CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
• Issues have been created for any UI or other user-facing changes made by this pull request.
• [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

[starcke]

Looks pretty good to me. But probably also good to get a second review from Charis as it is touching some existing code.

[starcke]

I am ok to do it like this for now. But it feels like we should be able to reuse the previous query as it selects all the same data.

[koesie10]

I found a way to use a single query for this, so I'll change it to use a single query for both retrieving the external APIs and for retrieving the usages.

[charisk]

Thanks for doing this! The approach looks good to me but I'm worried about the extensive use of Pick/Omit, specially for code outside of the data extensions editor/auto-model. Can we avoid these changes?

[charisk]

LGTM. I'll defer the CodeQL query changes to @starcke.

[charisk]

Sorry this is probably a stupid question, but why would a column not have a name?

[koesie10]

This is dependent on the query. In the query we're now using, the BQRS column definitions look like this:

[
  { name: "usage", kind: "Entity" },
  { name: "apiName", kind: "String" },
  { kind: "String" },
  { kind: "String" },
]

CodeQL is probably not naming the last two columns because it can't automatically determine a name based on the name of a variable:

usage, apiName, supported.toString(), "supported"

[starcke]

Query looks good to me. It is similar to the approach the CodeML queries have.