Update cargo regress tool and move CI

[robamu]

• CI now uses the svd2rust-regress tool instead of a bash script
• Fixed a bug where the workspace TOML file was still updated and changed
  when running the regression tool
• Upgrade portable-atomic version for CI checks to 1.
• Introduce MSRV v1.82.0 for the regress tool.
• Allow passing multiple passthrough options to the regress tool.
• Allow passing options using the test YAML file using the opts key
• Allow specifying a suffix for test cases inside the YAML file using the suffix key.
  This can be used to resolve name duplications.
• Allow skipping the cargo check for test cases with a skip_check key
  inside the YAML file

[robamu]

I don't know if I can enable CI for my own fork, that would be useful for testing..

[burrbull]

cc @Emilgardis

[Emilgardis]

we could use a

outputs:
    matrix: ${{ steps.generate-matrix.outputs.matrix }}

job

which would convert the matrix in this file to

strategy:
  fail-fast: false
    include: ${{ fromJson(needs.generate-matrix.outputs.matrix) }}

however, that wouldn't test different command flags. So maybe we shouldn't do that and instead just have a single job to test all defined test targets in svd2rust-regress

[robamu]

How would the input specification via a different job help? Wouldn´t one command mean that there are no individual CI jobs for the architecture and flag options anymore? I think this is a good thing in the current setup.. I tried to preserve the old setup here.

[Emilgardis]

I do this in cross-rs, where I have a targets.toml that populate the CI automatically through a ci job to filter targets.

The input basically expands to a list of targets, not just a single target in a list

[robamu]

This would probably be useful to make running the tests as they are done in the CI locally, even though it makes the CI chain a bit more complex.. But it might be better for a different PR?

[robamu]

I think this is getting to a good state now. The only problematic thing is that I had to disable the checks for MSP430. When I try to do a cargo check (locally, but same problem in CI) here, I get errors that some external C function specified in some dependency is not valid for the target.. I don´t know why this wasn´t an issue with the previous CI. It might work when using the correct target, but that required a few steps like building the core library for the MPS target and also installing a GCC cross-compiler for MSP430.

@burrbull I did not update the changelog, because this is only related to internal tooling. Should I still add a changelog entry?

[Emilgardis]

no changelog is needed for this

[robamu]

Fixes #689

Let's merge this now. If there is more issues we can fix them in another PR