Not allowing this makes stuff like anvil damage, colour, wood type, live/dead bit, wet/dry etc all too much hassle to deal with.
Naturally I want to get rid of this shit altogether, but first it's necessary to construct a new system that we can shift into before all this bullshit can be addressed fully, so for now we have to work within the bounds of the old system.
This change will permit dynamic colours for concrete/concrete powder etc, dynamic wood types where the wood type isn't embedded in the legacy ID, and so forth. Allowing full flexibility requires either more old system hacks or completing the migration to a new system which doesn't have these limitations. I prefer to do the latter, but this change will make it somewhat easier to do.
This test is intended to enforce that the BlockFactory always has the same blocks in it from one commit to the next. Since there are a lot of changes going on right now around this, it's important that this is checked because bugs can go under the radar when large changes are happening.
The consistency check will need to be regenerated whenever a new block is registered, new states are found or when things are removed.
this is a bad fix, but it doesn't matter a whole lot. The problem stems from furnace not having a valid 0 variant, so things go haywire when the default mapped 0 variant is registered to LIT_FURNACE because the default state is of course unlit.
This is a major change to the way block metadata is handled within the PM core. This separates variant metadata (which really ought to be part of the ID) from state metadata, and in a couple of cases flattens separate states of blocks together.
The result of this is that invalid variants can be much more easily detected, and additionally state handling is much cleaner since meta is only needed at the serialize layer instead of throughout the code.
