Add UnbakedModelDeserializer

[PepperCode1]

This pull request introduces the UnbakedModelDeserializer interface, which allows overriding the deserialization process of a JSON model file based on its fabric:type JSON key.

Points to Discuss

• Should optional types be allowed? That is, if a type is declared as optional in the JSON file and the type does not exist, the file will be loaded as if no type were declared instead of failing to load. I am not familiar with how Fabric API load conditions work or whether they are used when deserializing models, but if they are, then they could be an alternative approach to this idea.
• Should utilities to deserialize vanilla model elements (elements, parent, textures, ambientocclusion, display, gui_light) be provided? If so, how?
• Should data generation classes be extended to make it easier to generate models of custom types? If so, how?
• Which default custom types should be registered by Fabric API, if any? NeoForge provides a composite model type and an OBJ model type.
• Should UnbakedModelDeserializer have a method to retrieve its Identifier like CustomIngredientSerializer instead of the ID being passed to the register method directly?
• Should UnbakedModelDeserializer be generic? It represents a "type" which can create instances, and such classes are almost always generic both in Fabric API and vanilla.
• Are there better names for certain things?

TODO

• Documentation

[cputnam-a11y]

Is load conditions the same thing as resource conditions? if so, https://github.com/FabricMC/fabric/blob/1.21.4/fabric-resource-conditions-api-v1/src/main/java/net/fabricmc/fabric/impl/resource/conditions/ResourceConditionsImpl.java#L66-L87 is the implentation. If a type is not specified, the resource is loaded as normal, as if all conditions passed

[Technici4n]

• optional types: yes, they are useful
• utilities: only if we need them in FAPI for now, otherwise defer for later
• datagen: don't think about it for now
• custom types: can come later
• how to pass the identifier: it does not really matter. Passing it when registering is closer to how vanilla normally registers things.
• should the deserializer be generic? It doesn't really matter I think.

[Technici4n]

Missing javadoc

[Technici4n]

Missing javadoc, especially with regards to the context.

[Technici4n]

Why RuntimeException rather than a Gson one?

[PepperCode1]

It is acceptable for the deserializer to throw any RuntimeException, such as InvalidIdentifierException. The vanilla JsonUnbakedModel deserializer does that.