these started to get flattened in 1.19, and rather than dump them in random places in the main function I made a new method, creating placement inconsistencies.
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.
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
