Audit and update Rust dependencies

[simolus3]

This is a small follow-up to #212, which introduced SBOMs for core extension binaries.

This PR:

1. Builds the SBOM unconditionally, and uses that in tests to run a vulnerability scanner on it. This also has the benefit of implicitly validating the SBOM.
2. As there happens to be an issue in the serde_with version we use, this updates Rust dependencies through cargo update. We're not affected by that issue.
3. Expands dependabot to keep updating Rust dependencies. I've configured a monthly interval for that to avoid spam.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[rkistner]

The sarif upload appears to have failed:

Error: Code Scanning could not process the submitted SARIF file:
locationFromSarifResult: expected artifact location

It would be good to see what it looks like when results are uploaded.

I see the same vulnerability is also picked up here: https://github.com/powersync-ja/powersync-sqlite-core/security/dependabot/4. I assume this does essentially the same thing, but on the pruned dependency tree from #212?

[simolus3]

I assume this does essentially the same thing, but on the pruned dependency tree

Yes. I wasn't aware of the existing analysis, I think it's still helpful to fail the build if a vulnerability is found in code we end up shipping though.

It would be good to see what it looks like when results are uploaded.

I think this is an unfortunate effect of the scanning action failing the build without emitting the sarif file. I'll see if we can invoke the scanner twice, once to generate the report and once to fail the build.

[simolus3]

Ok, the actual cause of the upload failure is that generated sarif files only contain the message but no source location for which GitHub could show an alert.

That's unfortunate, I've switched to failing the build and showing a table of found issues now.