this information will allow us to correct for any bugs introduced by past versions.
however, we still need to propagate this information to permit actually using it when loading data.
to be consistent, these shouldn't be exposed in the API like this...
I'm not very happy with the whole 'type ID map' paradigm (particularly its lack of static analysis guarantees), but the most important thing right now is to get this stuff out of the API so that plugin devs don't try and abuse it. We're not going to change the whole system days before PM5 release.
At the time when I wrote this code, I was still in the head space of the kind of ID hijacking that PM4 plugins do to override built-in blocks.
However, this kind of internal ID reuse makes no sense in PM5, since said IDs are only used in the core itself at runtime to identify types and states.
Even if we were to allow overriding block deserializers, overriding serializers makes no sense whatsoever, since the original block would continue to exist and be accessible.
There is a case to be made to allow overriding the deserializer, but not for the serializer.
right now, I don't see an obvious reason to do this. If it turns out I was wrong later on, we can add functionality back, but we can't remove functionality after release.
this significantly reduces the size of schemas when state remaps are used (see pmmp/BedrockBlockUpgradeSchema@85b83b360e).
in addition, this will likely offer a substantial performance and memory saving when walls get flattened, which will eventually happen.
since PHP emits empty JSON objects as arrays, this makes it pretty annoying to work with the schemas in other languages. However, nullability is something most languages understand pretty easily.
This should continue to support old schemas.
these files were only kept for backwards compatibility, and aren't actively maintained. They are only needed for legacy conversions in the modern day era.
due to technical limitations, this requires separating them back into two different block types. However, this isn't too egregious since it's just one flag, and actually simplifies some code.
closes#5478
