feat: wasm32-unknown-unknown support for single-chain sampling

[habakan]

Motivation

I'd like to make sample_sequentially available from Rust crates compiled to wasm32-unknown-unknown.

This would benefit anyone embedding nuts-rs in a WebAssembly environment — browser-based inference tools, edge runtimes, or other languages with a wasm FFI.

Proposed changes

Several parts of the codebase depend on features not supported on wasm32-unknown-unknown (e.g. rayon, std::thread). The proposal is to introduce conditional compilation via cfg(not(target_arch = "wasm32")) for those parts. No existing public API is removed.

• Move rayon to [target.'cfg(not(target_arch = "wasm32"))'.dependencies]
• Add getrandom = { version = "0.4", features = ["wasm_js"] } under [target.'cfg(target_arch = "wasm32")'.dependencies] (required for rand's RNG on this target)
• Gate Sampler, ChainProcess, ProgressCallback, SamplerWaitResult and their related imports behind #[cfg(not(target_arch = "wasm32"))]
• Gate the corresponding re-exports in lib.rs

sample_sequentially and the core NUTS machinery (Chain, CpuMath, CpuLogpFunc, settings types) require no changes and work as-is on wasm32.

Impact on existing users

• Native builds are unaffected. rayon remains a dependency for all non-wasm32 targets and Sampler continues to be exported.
• nutpie's parallel multi-chain sampling via Sampler is unchanged on native targets.
• The gated types are ones that cannot function on wasm32 regardless, so this is not a meaningful API removal.

Questions before opening a PR

1. Is this a direction you'd be open to accepting?
2. Should I add a cargo check --target wasm32-unknown-unknown step to CI as part of the PR?
3. Do you have a preference for how to handle the getrandom wasm_js feature (target-specific dependency vs. another approach)?

I have a working implementation on a branch if you'd like to take a look:

• habakan/nuts-rs feat/wasm32-support
• commits