feat: add support for cargo-auditable data format

[alex-ter]

Description

Implement support for cargo-auditable. This is a developing (but already seeing adoption in the industry) standard for storing SBOM data directly in Rust binaries upon building them. The data is a Zlib-compressed JSON embedded into a dedicated executable file section.

Why?

The approach used by cargo-auditable IMHO only makes sense and looking at the initial discussion in the corresponding Rust RFC, it looks like this is likely to eventually land in mainline Cargo, after that prerequisite SBOM RFC they mentioned is stabilized. Other than this being relatively early days for this standard/approach, this fits perfectly into cve-bin-tool's scope and mission, so it also only makes sense to support this.

Additional points and considerations

I'm willing to and interested in implementing this functionality in cve-bin-tool with only minor guidance from maintainers on specific technical points as they arise, if this idea is accepted.

Open points I can think of right away:

1. This functionality seems to sit between a "language support" and a "checker" in the current cve-bin-tool terminology, as the data is in actual binaries, but this is language-specific. Any comments on which one should this be are more than welcome. I'm a bit more inclined to making it a checker, but I haven't yet investigated which way would require fewer changes or is a better fit technically.
2. The cargo-auditable project provides a ready-made and hardened data extraction crate (MIT/Apache 2.0 license, part of the original project), which we could use via one of the typical Python->Rust integration approaches. This would take care of format support evolution, [arguably] security, and performance, at the cost of integrating Rust crate and all the corresponding additional complexity in the cve-bin-tool. It is also possible to implement this support in pure Python and is an alternative I'm considering (probably via a dedicated library, to avoid piling it onto cve-bin-tool). I'm interested in your opinion here. Maybe given the existing ideas of speeding up some parts of cve-bin-tool using compiled code (number 6 in the GSoC 2025 list), this is not that far-reaching, after all?