Add Rust binary support

Rust is becoming a significant part of Red Hat's shipped products and tooling, and the FIPS scanners need to follow. check-payload has a dedicated Go pipeline and a generic ELF pipeline but no Rust arm, so Rust binaries go effectively unchecked.

Problem

check-payload has no Rust classifier, so Rust binaries fall through to the generic exe pipeline, which fails only static binaries and never requires linkage to the system OpenSSL. A Rust binary can do crypto through a vendored, static, or pure-Rust backend such as ring, aws-lc-rs, vendored openssl-sys, or RustCrypto like sha2. Any of those passes the scan without reaching the validated module. Today Rust binaries surface only as one-off exceptions, for example ripgrep in #357, never as a validated crypto path.

Why it matters

Rust is arriving in OpenShift payloads and operator images. FIPS requires every crypto operation to run in the system OpenSSL FIPS provider, dynamically linked with nothing vendored. check-payload cannot yet tell a compliant Rust binary from a non-compliant one.

Proposed direction

No single check is sufficient, so a Rust classifier feeds a pipeline that layers three:

• dynamic linkage to the system libcrypto, proving the binary reaches the validated module,
• a symbol-table scan for self-contained backends like ring or vendored OpenSSL, needing no SBOM,
• the cargo auditable SBOM, for pure-Rust crypto the symbols cannot see.

Known limit

Each layer covers a gap the others leave. ELF inspection misses pure-Rust crypto like sha2. It exposes no stable C-ABI symbol to fingerprint, and release builds strip its mangled Rust symbols. That class rests on the cargo auditable SBOM embedded at build time. A Hermeto or Konflux SBOM does not substitute, since it comes from Cargo.lock and over-reports crates the build never compiled (https://github.com/orgs/hermetoproject/discussions/1769).

Happy to work up the detail if useful.