Please review: initial `no_std` scaffolding across crates

[mparkachov]

Hello Steel community! I’m teaching myself Rust and have been experimenting with Steel on an ESP board. The PoC ran with std because that board exposes a few standard APIs, but I quickly started hitting memory ceilings. To see if we can slim things down I sketched out what a no_std build might look like. This issue is an initial proposal to sanity check the approach and to hear whether full no_std support is something we want to pursue.

Overview

• Introduces dedicated CI coverage for no_std targets with custom rustflags and a wasm test harness (.github/workflows/no_std.yml:1, .cargo/no_std.toml:1, scripts/no_std_runner.js:1).
• Reworks steel-core’s feature graph so std dependencies are optional and adds minimal fallbacks plus a custom getrandom shim to keep the crate compiling without std (crates/steel-core/Cargo.toml:115, crates/steel-core/src/lib.rs:1, crates/steel-core/src/minimal.rs:1, crates/steel-core/src/getrandom_custom.rs:1).
• Splits std-only functionality into gated modules for supporting crates and supplies placeholder implementations for no_std builds (crates/cargo-steel-lib/src/lib.rs, crates/cargo-steel-lib/src/minimal.rs, crates/steel-gen/src/lib.rs, crates/steel-parser/src/lib.rs, crates/steel-parser/src/pretty.rs).
• Adds a portable test harness so core smoke tests can run under no_std with custom allocator support (crates/steel-core/tests/no_std_suite.rs:1, crates/steel-core/tests/portable.rs:1).

Notes

• Parser builds in the workflow still run under continue-on-error, so the no_std story there is incomplete (.github/workflows/no_std.yml).
• Some pieces are stubbed just to unblock compilation (e.g., the cargo-steel-lib runner currently returns an unsupported error in no_std, crates/cargo-steel-lib/src/minimal.rs).

This is an initial proposal whose goal is simply to get the workspace compiling with no_std.

Next steps

1. Split the regression suite so both std and no_std modes get dedicated coverage, using the wasm runner to surface real pass/fail signals.
2. Replace temporary stubs (cargo-steel-lib runner, parser pretty-printing, deterministic getrandom shim) with working implementations or tighter cfg gates.
3. Resolve the remaining build failures so we can drop continue-on-error from the workflow and reach parity with current std builds.

[mattwparas]

What were the memory ceilings you hit? There are things that can probably be tuned to reduce the memory footprint in general and make gc more aggressive in constrained environments.

Otherwise, I'm not opposed to a no std feature, although I'm not sure if it is entirely possible; I haven't made anything no std before so I'd have to poke around a bit

[mparkachov]

Linked PR: #583