Implement Redstone foundation and other improvements

[4lve]

This PR implements redstone based on the vanilla implementation, meaning that behavior such as locational redstone should work correctly.

Redstone implementation

The implementation mirrors vanilla’s signal queries, neighbor update ordering, scheduled ticks, and block-specific behavior. This includes redstone wire, torches and burnout, repeaters, comparators, observers, pistons, rails, pressure plates, buttons, levers, tripwire, daylight detectors, lamps, target blocks, copper bulbs, redstone ore, and the relevant comparator sources and powered block reactions.

Supporting systems such as dynamic block shapes, moving piston block entities, block event handling, directional placement, and chained neighbor updates were also implemented or improved where redstone depended on them.

Ticking changes

During Steel’s early development, I had the idea that since we were forced to iterate over every chunk each tick anyway, we might as well tick block entities and random blocks there too. Since then, Steel has gained simulation distance and multiple levels of chunk ticking/readiness. This, alongside the performance benefits, changed my mind. Scheduled ticks are now sparse and chunk-owned, while random and block entity ticking only process relevant chunks and sections.

Another issue I noticed was that joining the game caused tick times to spike massively, sometimes putting 1 to 3 ticks above our 50 ms warning threshold. Profiling pointed toward chunk post-processing and leaves updating their distance from logs. I first added a recent chunk lookup cache so every World::get_block_state call would not require an scc::HashMap lookup. This only went so far, since the scheduled leaf ticks still ran sequentially on the game tick.

Ultimately, I wrote a leaf-distance propagator that runs during the InitializeLight generation stage. This lets us optimize and parallelize the work while keeping live in-game leaf behavior the same. Post-processing still runs on the game tick, but I plan to parallelize it in the future; this is currently blocked by the collecting neighbor updater.