Produce qlpacks as a build artifact

[lcartey]

Description

This PR amends our automation and release process to produce qlpacks in addition to the existing bundle:

• The existing compilation of queries in .github/workflows/code-scanning-pack-gen.yml is modified to (a) perform all compilations in a single step (instead of separately for c and cpp), and (b) increases the compilation cache size to ensure we retain the cached compilations for all Coding Standards queries.
• A new step is added to .github/workflows/code-scanning-pack-gen.yml to generate qlpacks in a .tgz format. This uses the cached compilations, and should be quick to complete.
• The new packs are uploaded as an artifact with the name coding-standards-qlpacks. This should be generated for every PR and push to main, as with the existing artifact.
• release-layout.yml is updated to include the new artifact. This should ensure that the artifact is copied onto releases in a similar way to the existing code-scanning-cpp-query-pack.ql artifact.

This PR does not attempt to change our release process to publish the generated packs - only add them as an artifact to the release page. For the next release I plan to manually push the packs to the registry, and look to automate for following releases.

Change request type

• [x] Release or process automation (GitHub workflows, internal scripts)
• [ ] Internal documentation
• [ ] External documentation
• [ ] Query files (.ql, .qll, .qls or unit tests)
• [ ] External scripts (analysis report or other code shipped as part of a release)

Rules with added or modified queries

• [x] No rules added
• [ ] Queries have been added for the following rules:
  • rule number here
• [ ] Queries have been modified for the following rules:
  • rule number here

Release change checklist

A change note (development_handbook.md#change-notes) is required for any pull request which modifies:

• The structure or layout of the release artifacts.
• The evaluation performance (memory, execution time) of an existing query.
• The results of an existing query in any circumstance.

If you are only adding new rule queries, a change note is not required.

Author: Is a change note required?

• [x] Yes
• [ ] No

🚨🚨🚨 Reviewer: Confirm that format of shared queries (not the .qll file, the .ql file that imports it) is valid by running them within VS Code.

• [ ] Confirmed

Reviewer: Confirm that either a change note is not required or the change note is required and has been added.

• [x] Confirmed

Query development review checklist

For PRs that add new queries or modify existing queries, the following checklist should be completed by both the author and reviewer:

Author

• [ ] Have all the relevant rule package description files been checked in?
• [ ] Have you verified that the metadata properties of each new query is set appropriately?
• [ ] Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• [ ] Are the alert messages properly formatted and consistent with the style guide?
• [ ] Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• [ ] Does the query have an appropriate level of in-query comments/documentation?
• [ ] Have you considered/identified possible edge cases?
• [ ] Does the query not reinvent features in the standard library?
• [ ] Can the query be simplified further (not golfed!)

Reviewer

• [ ] Have all the relevant rule package description files been checked in?
• [ ] Have you verified that the metadata properties of each new query is set appropriately?
• [ ] Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• [ ] Are the alert messages properly formatted and consistent with the style guide?
• [ ] Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• [ ] Does the query have an appropriate level of in-query comments/documentation?
• [ ] Have you considered/identified possible edge cases?
• [ ] Does the query not reinvent features in the standard library?
• [ ] Can the query be simplified further (not golfed!)

[lcartey]

@knewbury01 I've updated to address your latest comment, and added a release note.