mushroom stem (and all-sided stem) are unique blocks, which don't drop anything and which don't stack with other shroom variants when block-picked.
They also get mapped to the same block when placed, and there's no distinction between red mushroom stem and brown mushroom stem.
when using VanillaBlocks::CHISELED_QUARTZ(), VanillaBlocks::PURPUR_PILLAR() or VanillaBlocks::QUARTZ_PILLAR(), static analysis was unable to detect getAxis() and setAxis(), because these blocks were implemented using anonymous classes.
there are some complications with coral plants due to the fact we're stuck with R12 worlds right now - and also coral fans are a major pain to implement due to how messed up the metadata is.
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 new form allows skipping some useless checks during sky light calculation and also allows getting rid of the last hard dependency on core Block classes.
We're getting real close to native light now.
Now, blocks do not respond to silk touch unless specifically opted into. Since this always involves custom drops in one way or another, it's easy enough to figure out which blocks need to be marked for silk touch - anything that overrides getDrops, getDropsForCompatibleTool or getSilkTouchDrops is a block which _might_ need to be flagged. Using these criteria to reduce the number of blocks needing to be checked, I was able to manually invert the behaviour as needed.
This fixes reoccurring bugs with blocks erroneously dropping themselves whenever new blocks are added and someone forgot to set that flag, granting players access to internal blocks with strange behaviour.
technically there wasn't anything wrong with this code, but it caused the type inference to report incompatibility, and I can't be bothered to report a PHPStan bug.
