Rotation design is inconsistent

[kpreid]

In the current design, the rotation of a block is a function (computed by a circuit in the block) of the state of the block, and so it is not itself mutable state.

However, this is problematic; for example, if the circuit contains a neighbor sensor, then the result of that sensor depends on the direction of that sensor, which depends on the rotation. Going by data dependencies, this is undefined. Going by an imperative update model (which is not how rotations were supposed to work) we could make a block which spins forever.

(A related issue I previously noticed is that the indicator behavior, which really shouldn't be primitive, cannot be implemented using primitives, and that was on purpose because rotation determines circuit connectivity so block circuit evaluation is isolated from IC evaluation.)

Options I've thought of so far:

1. Add rotations as explicit block state, perhaps along with some bit packing of some description so we're not adding a whole 'nother byte just for the purpose. (The original motivation for deriving rotations from the subdatum was so that blocks which are non-rotatable could fully use the data for other purposes.)
2. Make all circuit functionality independent of block rotation. Then, rotatable blocks with directional behaviors would have to internally implement logical rotation of their sensors/effectors to match their physical rotation. This seems like the long way around.

[kpreid]

I've done some more thinking on this and I am thinking — that the answer here is “do what Minecraft (now) does”, that is, take option 1 above (rotations are explicitly part of the block state the game engine understands) but implement it less as a rotation feature and more as general “this single block definition has the following programmatically-derived variations”.

This would imply replacing block ID numbers with some sort of more structured reference (but I wanted to do that anyway), and allowing blocks to address their “sibling block types” so that they can rotate themselves.

I think adding the idea of "(parts of) blocksets as functions of other blocksets" would solve several problems, such as the one where we currently have the circuit-block definitions programmatically pasted into lots of blocksets and there's no good way to update them.