support new cargo error in rust 1.95

[syphar]

see failure in this other CI run.

[96](https://github.com/rust-lang/rustwide/actions/runs/24624191683/job/72000147371#step:6:197)
 rustwide::cmd] [stderr]     Updating git repository `[https://github.com/rust-lang/rustwide.git`](https://github.com/rust-lang/rustwide.git%60)
 rustwide::cmd] [stderr] error: invalid character `!` in package name: `!`, the first character must be a Unicode XID start character (most letters or `_`)
 rustwide::cmd] [stderr]  --> ../../../cargo-home/git/checkouts/rustwide-42b79ae0da483ace/07784be/tests/buildtest/crates/invalid-cargotoml-content/Cargo.toml:2:8
 rustwide::cmd] [stderr]   |
 rustwide::cmd] [stderr] 2 | name = "!"
 rustwide::cmd] [stderr]   |        ^^^
 rustwide::cmd] [stderr] error: key with no value, expected `=`
 rustwide::cmd] [stderr]  --> ../../../cargo-home/git/checkouts/rustwide-42b79ae0da483ace/07784be/tests/buildtest/crates/invalid-cargotoml-syntax/Cargo.toml:1:9
 rustwide::cmd] [stderr]   |
 rustwide::cmd] [stderr] 1 | Invalid!
 rustwide::cmd] [stderr]   |         ^
 rustwide::cmd] [stderr] error: patch location `https://github.com/rust-lang/rustwide.git?rev=07784be00b68cfd6bf80006c8d8669a7d6374ec2` does not contain packages matching `build-rs`
 rustwide::cmd] [stderr] help: check `build-rs` patch definition for `[https://github.com/rust-lang/crates.io-index`](https://github.com/rust-lang/crates.io-index%60) in `/home/runner/work/rustwide/rustwide/.workspaces/integration/builds/invalid-cargotoml-missing-patch-FzLmTQjDou/source/Cargo.toml`

thread 'buildtest::test_invalid_cargotoml_missing_patch' (10055) panicked at tests/buildtest/mod.rs:430:1:
expected PrepareError::MissingDependencies error, got Uncategorized instead
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    buildtest::test_invalid_cargotoml_missing_patch

similar PR in #106.

[syphar]

r? @Skgland

I think we should also cover that old releases still work in our CI, not only the most recent one.

Do you have thoughts on that? Or did we when we implemented this?

[Skgland]

r? @Skgland

I think we should also cover that old releases still work in our CI, not only the most recent one.

Do you have thoughts on that? Or did we when we implemented this?

Sounds reasonable.

If I remember correctly, then I adjusted the expected output to a common substring so I would work with both old and new version, though that is likely infeasible long term, so we might want a set/list of expected outputs instead.

Would that also entail running CI against more version? Currently it appears to run only against stable. I would suggest to at least add a beta.

[syphar]

Would that also entail running CI against more version? Currently it appears to run only against stable. I would suggest to at least add a beta.

question for me is more around old versions. If I imagine us refactoring this part of the codebase, CI should validate if it still works with the old versions.

But that being said: with the existing use-cases I'm not sure if doing that is worth the complexity.