Add voxel manipulation about hypermine

[patowen]

An optional but likely helpful quality-of-life feature would be to push the player up to a certain distance away from a block being placed. This is a bit tricky to implement but not intractable. There are two problems that this can help resolve:

• If a player pushes up against a wall, breaks it, and tries to replace it, they should ideally succeed, but it is tricky to guarantee this without the player potentially clipping through the placed block.
• If the player walks past a ledge with the goal of placing a block horizontally to extend the ledge, the spherical collision region of the player will have them move downward, causing them to be in the way of the block that would be placed.

However, this quality-of-life feature is likely out of scope for this particular issue, as it has some challenges:

• We need to decide which direction to push the character. It is likely the answer is "whichever direction yields the shortest distance", but some unanticipated artifacts could appear from that decision. Another option is "always up", although this would only solve the bridging problem.
• To work in corners, multiple iterations of collision resolution may be needed. After redirecting the movement direction, the character still needs to move far enough to stop intersecting the voxel being placed.
• If the player is on the ground, this feature might make them leave the ground when placing a block, which could be jarring, so some prevention may be needed for that.
• This feature would cause discontinuities in the player's position that would require some kind of interpolation to correct.

[patowen]

While the server has one view of the world, the client seems to have three:

• Last updated world-state given by the server
• Predicted world-state, updated per step
• Extrapolated world-state, updated per frame

Currently, all ECS components use the first view (last updated world-state given by the server), as prediction.rs stores everything about the second view (predicted world-state, updated per step), and client's sim.rs computes the third view (extrapolated world-state, updated per frame) on the fly.

If we don't want this long-term, I believe this feature (block placing/breaking) is a good time to revisit this, since we'll need the world's voxels to have prediction data (I don't think per-frame extrapolation data is needed, fortunately). This could just live in prediction.rs, since voxels aren't an entity anyway, but only if we're happy with organizing the code that way.