no_std and WASM blocked by rand/regex deps

[loadingalias]

Problem

The crate cannot be used in no_std environments or build for WASM targets because rand and regex are listed as runtime dpes, but are only used in benches and tests.

Impact

• Cannot build for wasm32-unknown-unknown (fails with getrandom error)
• Cannot build for embedded targets (thumbv6m-none-eabi, etc.)
• Unnecessary dependencies for library users

Root Cause

From Cargo.toml:

[dependencies]
rand = "0.9"       # Only used in benches/tests
regex = "1.12"     # Only used in tests

Actual usage:

• rand: Only in benches/benchmark.rs and test code in src/lib.rs
• regex: Only in test test_ffi_header() in src/lib.rs

Suggested Fix

Move to dev-dependencies:

[dev-dependencies]
criterion = "0.7"
cbindgen = "0.29"
rand = "0.9"
regex = "1.12"

This immediately enables:

• WASM & no_std/embedded builds
• Cleaner dependency tree for users

NOTES:
There are no actual code changes needed here. I think it's just moving the rand and regex to [dev-dependencies]! Please, and thank you.

[onethumb]

@loadingalias Alas, src/bin/checksum.rs now depends on rand for benchmarking as of 1.6.0.

   Compiling crc-fast v1.6.0 (/Users/onethumb/git/rust/crc-fast-rust)
error[E0432]: unresolved import `rand`
 --> src/bin/checksum.rs:6:5
  |
6 | use rand::RngCore;
  |     ^^^^ use of unresolved module or unlinked crate `rand`
  |
  = help: if you wanted to use a crate named `rand`, use `cargo add rand` to add it to your `Cargo.toml`

error[E0433]: failed to resolve: use of unresolved module or unlinked crate `rand`
   --> src/bin/checksum.rs:163:19
    |
163 |     let mut rng = rand::rng();
    |                   ^^^^ use of unresolved module or unlinked crate `rand`
    |
    = help: if you wanted to use a crate named `rand`, use `cargo add rand` to add it to your `Cargo.toml`

I'd like to resolve this, so I'm open to ideas (or, better yet, a PR :). I'll think about it, too.

[loadingalias]

Hey, I'll submit the PR in the next few hours.

EDIT
WASM Compatibility Done; Prepped for 'no_std' and I'm working on that now. I think I'd feel better if you gave me a tiny bit of direction with respect to the no_std updates. You've done brilliant work here and I don't want to skew too far from the plan.