Support no_std builds

[dharjeezy]

Draft: blocked on ethereum_serde_utils#21. CI here will fail dependency resolution until that is merged and released. Opened now so the whole series is visible rather than arriving piecemeal.

What this does

Adds no_std support, so the crate can be used from a wasm runtime, plus two smaller changes that no_std consumers need.

Why

Substrate runtimes compile to wasm32-unknown-unknown without std. Everything here is available in core and alloc.

Changes

Commit	What
Support no_std builds	crate gated on the std feature, alloc used where std was assumed
Give BitList a Default impl to match BitVector	BitVector already had one, the asymmetry is awkward for derived containers
Emit core paths from the derives	the generated code referenced std:: paths, so it did not compile in a no_std consumer even when this crate itself did
Satisfy the current clippy lints	housekeeping the tooling flagged while working here

The derive change is the one that matters most for downstream users. A no_std crate could depend on this one successfully and still fail to build the moment it used #[derive(Encode)].

Why it cannot build yet

This depends on ethereum_serde_utils with feature std, and the published 0.8.1 has no such feature: it is added by #21. Until that releases, cargo cannot resolve.

Verification

Verified locally against the proposed ethereum_serde_utils branch via a path patch.

Check	Result
cargo test	123 + 41 passed
cargo check --no-default-features --target wasm32-unknown-unknown	clean
cargo fmt --check	no diffs

Where this sits

1. ethereum_hashing#23 and ethereum_serde_utils#21
2. this PR
3. tree_hash, then ssz_types

Happy to rework any of it, and glad to split the clippy commit out if you would rather review the no_std work alone.