Feat: SBOM vulnerability scan

[brynpickering]

• Uploads pixi default deps to github dependency list
• Uploads identified vulnerabilities to codeQL vulnerabilities list
• Identifies vulnerabilities on updates to pixi.lock
• Move unnecessary deps from default to dev env (jupyter introduces npm ip package vulnerability cvs-2024-29415).

As is ever the case with these kinds of PRs, I find it impossible to successfully test the workflows locally, even with act (docker and osx-arm64 aren't the best of friends). So, I don't know for sure that they work as expected...

What you get:

1. on successful merge of the lockfile updater PR into master, the repo dependencies are uploaded to the github API so they are correctly represented in the dependency graph.
2. on successful merge of the lockfile updater PR into master, the latest identified vulnerabilities are uploaded to the repo CodeQL vulnerability list.
3. on any change to pixi.lock in a PR to master, a comment is added with a table of vulnerabilities identified in the updated env.

Note

PR comment doesn't work correctly in PRs from forks, as noted by the action maintainer. We could update this to be triggered on pull_request_target but there are other concerns then about vulnerabilities introduced by bad actors via the action.

This is all needed because native github tools (CodeQL & dependabot) don't analyse pixi.lock files.

Required:

• Changes are tested locally and behave as expected.
• Code and workflow changes are documented.
• A release note entry is added to doc/release_notes.rst.

If applicable:

• Changes in configuration options are reflected in scripts/lib/validation.
• For new data sources or versions, these instructions have been followed.
• New rules are documented in the appropriate doc/*.rst files.