fix some fuzzing conditional compilation issues in aptos-crypto

[alinush]

Description

Was trying to add a new signature benchmark and noticed that cargo test now fails in crates/aptos-crypto due to some conditional compilation gone awry in #14869 (cc @zi0Black):

alinush@alinush [~/aptos-core/crates/aptos-crypto] (alin/fix-crypto-benches) $ cargo test
   Compiling aptos-crypto v0.0.3 (/Users/alinush/repos/aptos-core/crates/aptos-crypto)
error[E0592]: duplicate definitions with name `from_bytes_unchecked`
  --> crates/aptos-crypto/src/secp256r1_ecdsa/secp256r1_ecdsa_sigs.rs:52:5
   |
39 | /     pub(crate) fn from_bytes_unchecked(
40 | |         bytes: &[u8],
41 | |     ) -> std::result::Result<Signature, CryptoMaterialError> {
   | |____________________________________________________________- other definition for `from_bytes_unchecked`
...
52 | /     pub fn from_bytes_unchecked(
53 | |         bytes: &[u8],
54 | |     ) -> std::result::Result<Signature, CryptoMaterialError> {
   | |____________________________________________________________^ duplicate definitions for `from_bytes_unchecked`

For more information about this error, try `rustc --explain E0592`.
error: could not compile `aptos-crypto` (lib test) due to 1 previous error

Not sure why CI did not catch this.

cc @aptos-labs/prod-eng: is cargo test not being run for crates/aptos-crypto in CI?

How Has This Been Tested?

cargo test in crates/aptos-crypto now compiles:

Key Areas to Review

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

[trunk-io]

⏱️ 17m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
rust-move-tests	13m	🟩
rust-cargo-deny	2m	🟩
check-dynamic-deps	1m	🟩
general-lints	24s	🟩
semgrep/ci	20s	🟩
file_change_determinator	9s	🟩
permission-check	2s	🟩
permission-check	2s	🟩

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

[zjma]

it seems the code for this case the other case are identical.