Optimize jigsaw free space tracking with cuboid difference shapes

[gurrveerrrr]

Fixes #235

Jigsaw structure generation spends a lot of time repeatedly combining VoxelShape while checking and subtracting free space. This replaces that hot path with a lightweight cuboid-difference representation that avoids building voxel shapes for the common case.

The fast path handles vanilla jigsaw placement exactly while falling back to the original implementation for anything it can't represent (such as off-grid or modded shapes), preserving vanilla behavior.

Added randomized tests that compare the new implementation against vanilla across full placement chains, boundary cases, shared-list divergence, and fallback paths.

[2No2Name]

Have you checked the performance impact of these changes?

[2No2Name]

https://modrinth.com/mod/structure-layout-optimizer is a mod that optimizes this part of the code already I believe

[gurrveerrrr]

Have you checked the performance impact of these changes?

I haven't run proper benchmarks yet. I've mostly been focused on making sure it matches vanilla first, and all the randomized tests have been passing. Im right now running a microbenchmark that runs realistic jigsaw placement chains through both the vanilla Shapes.join path and the new cuboid-difference path and i'll share the results.

[gurrveerrrr]

https://modrinth.com/mod/structure-layout-optimizer is a mod that optimizes this part of the code already I believe

I think it's doing something a bit different. It looks like it reduces how many pieces get checked, while this changes how the free space is tracked

[gurrveerrrr]

Did some benchmarks with the same operation order that tryPlacingChildren does (free space join, reject check, subtract) using same inputs for both paths.

results:

small: 4.1ms -> 0.33ms (~13x)
medium: 146ms -> 0.26ms (~560x)
village size: 2355ms -> 0.33ms (~7200x)

the reason the gap gets so big is vanilla keeps re checking the growing voxel grid every time, while the new representation stays pretty much constant.

also found a issue while testing. calling VoxelShape methods on the new shape makes it materialize back to vanilla, which made my first results wrong. these numbers avoid that and match how jigsaw actually uses it.

this only tests the shape operations, not the full structure generation time. stuff like template loading is still the same, but since #235 showed these joins are a big bottleneck this should still help a lot.

also this should work alongside structure-layout-optimizer. that reduces how many checks happen, while this makes the checks cheaper.