Use reflection to locate BlockTypeIds and ItemTypeIds for VanillaBlocks/VanillaItems
Since BlockTypeIds and ItemTypeIds are derived from VanillaBlocks and VanillaItems respectively anyway (they only exist to allow identifying blocks/items without having to create instances of them), this hack is probably OK, and reduces the chances of mistakes.
Previously it was explored to have these IDs generated by auto-incrementing in VanillaBlocks/Items and have the constants generated that way, but this proved to be too problematic because of unstable diffs no matter how we chose to sort the elements. See #6313 for previous research on the subject.
This is obviously not a desirable hack to keep long-term. In the future it will probably make sense to redesign VanillaBlocks like so:
enum VanillaBlocks { ... }
VanillaBlocks::STONE (the type ID)
VanillaBlocks::STONE->new() (to create a block)
However, more research is needed on this, as I'd prefer not to make block creation any more verbose.
Added the following new blocks:
- All types of Copper Bulb
- All types of Copper Door
- All types of Copper Trapdoor
- All types of Chiseled Copper
- All types of Copper Grate
As discussed many years ago in #2551, no one actually knows what this property actually means. It definitely isn't the conventionally expected definition of 'solid' found in the real world, as signs are solid but flower pots are not.
we can safely assume this for blocks (though the type info doesn't reflect it) but this is not safe to assume for random APIs that might be used by plugins.
if there's no state data to encode, we can avoid useless calls and object allocations.
For the best cases (blocks which don't use state data at all) this improves the performance of getStateId() by more than 10x.
Blocks which use one or the other benefit by a smaller but still significant margin.
