Support no_std builds

[dharjeezy]

Part of a five crate series adding no_std support across the SSZ stack, so it can be used from a Substrate runtime. This one has no dependencies on the others and is ready to review. The order is ethereum_hashing#23 and ethereum_serde_utils#21 first, then ethereum_ssz#86, then tree_hash#53, then ssz_types#85. The later three are drafts because they cannot resolve until these two are released.

What this does

Adds no_std support, so the crate can be used from a wasm runtime.

Why

Substrate runtimes compile to wasm32-unknown-unknown without std. Everything this crate does is already available in core and alloc, so the only obstacles were the lazy static and a transitive std link through sha2.

Changes

Change	Reason
spin::Lazy under no_std, gated so std keeps LazyLock	LazyLock is unavailable without std, and this keeps the std path exactly as it was
sha2 switched to default-features = false	its default features pull in std, which defeats a no_std build even when nothing calls into it
crate level compile_error! naming the missing backend	with --no-default-features neither sha2 nor ring is enabled, and the resulting errors were previously a wall of unrelated messages rather than a clear cause

The std build is unchanged.

Verification

Check	Result
cargo test	7 passed
cargo check --no-default-features --features sha2 --target wasm32-unknown-unknown	clean
cargo fmt --check	no diffs

Happy to adjust the approach if you would rather solve the lazy static differently, or drop the compile_error! guard if you consider it noise.