Move various settings from non vanilla custom item data to custom item data and allow use in JSON mappings

[eclipseisoffline]

This PR moves various settings from the NonVanillaCustomItemData to the CustomItemData class, which is useful for datapack/server side mod developers when porting custom items to Bedrock using Geyser's mapping system.

Properties that have been moved to the super-interface:

• stackSize
• maxDamage
• attackDamage
• toolType
• toolTier
• armorType
• protectionValue
• isHat
• isFoil
• isEdible
• canAlwaysEat
• isTool - deprecated, won't be moved

The builders for these classes have been correctly updated, alongside the implementations of these classes and their use in CustomItemRegistryPopulator.

A few notes:

• The NonVanillaCustomItemData.Builder class has been given overrides for the moved properties to allow for full backwards compatibility.
• The private isTool boolean field in the implementation of NonVanillaCustomItemData (GeyserNonVanillaCustomItemData) has been removed and not re-implemented in its super class - it has been replaced with displayHandheld and wasn't used anywhere in the implementation anymore. It was not publicly available. The isTool method has been moved to the super-interface and redirects to the displayHandheld method (it is marked deprecated, like before).
• The constructor of GeyserCustomItemData has been simplified to simply take its builder as argument.
• To not change the behaviour when the stack size is unset when extending vanilla items (in that case the Java base item's stack size is used), the stack size property has been changed slightly in implementation, which shouldn't be noticeable for API users. The Javadoc has been updated correctly:

  • Returns 0 if not set. When not set (or 0), takes the Java item stack count when based of a vanilla item, or uses 64 when porting a modded item.

• To not change the behaviour when the max damage is unset when extending vanilla items (in that case the Java base item's max damage is used), the max damage property has been changed slightly in implementation, which shouldn't be noticeable for API users. The Javadoc has been updated correctly:

  • Returns -1 if not set. When not set (or below 0), takes the Java item max damage when based of a vanilla item, or uses 0 when porting a modded item.

• The createComponentNbt method for CustomItemData has been updated to continue supporting GeyserMappingItem as well.
• All properties moved are now supported in JSON item mappings as well, the MappingsReader_v1 has been updated accordingly.
• The wiki has to be updated to reflect the changes (I could make the PR).
• Unrelated to moving the properties, the implementation of the edible property has been updated to include the minecraft:use_modifiers Bedrock component alongside the minecraft:food component, which seems to now be required to make edible items behave correctly.

A couple of the new JSON mapping properties have been tested (stack_size, max_damage, hat and edible), and backwards compatibility of using builder methods in NonVanillaCustomItemData.Builder in extensions has been tested as well, which all seem to work okay.

Feel free to suggest any changes and I'll be sure to implement them!

[Camotoy]

Code looks fine to me, but will delegate to someone else for API approval.

[onebeastchris]

what's preventing us from inheriting the modded item's stack size?

[eclipseisoffline]

When Geyser registers the modded item mappings (in CustomItemRegistryPopulator#registerCustomItem), it doesn't actually have access to the properties of the (modded) Java item - all it knows is the properties specified in the mapping, and it creates a Java item instance from that (can be seen here). The current behaviour of modded item mappings is to default to 64 when no stack size is specified, which I copied in this PR.

Note that Geyser does have access to vanilla Java items, which is why it's able to copy the properties of those when creating a vanilla item mapping (here).

I'm not aware of a way for Geyser to automatically fetch the properties of a modded item - if there is, I could implement it in this PR.

[onebeastchris]

same as stack size above

[onebeastchris]

same as stack size above

[onebeastchris]

I'm not convinced that this (and all other moved api that isn't controlled by a component) should be moved here. lMO it makes more sense to inherit this from the base Java item, as is done in vanilla

[eclipseisoffline]

Hm, I was a bit conflicted on some of the moves.
The only properties that don't relate to a Java component at all are, I think, toolType, toolTier, armorType and isHat.

As for toolType and toolTier, there is a minecraft:tool component on Java, but I'm not sure what the functions of the toolType and toolTier properties are, and if/how they relate to the Java minecraft:tool component.

Same goes for the armorType property, though there isn't an armor component on Java - rather, armor attribute modifiers are in the minecraft:attribute_modifiers component.

As for isHat, I moved this because I think it can be useful for custom helmets making use of vanilla items with custom models. On the Java helmet slot, all vanilla items are always rendered, even with custom models, which allows for custom helmet models, while on Bedrock this requires the isHat property.
Additionally, mods like Polymer allow adding custom helmet items (appearing as vanilla items to the client) that can be equipped in the helmet slot on a vanilla Java client, so I thought it would be useful to copy this to allow for the same behaviour on a Bedrock client.