Item data components framework

[tal5]

Depends on DenizenScript/Denizen-Core#116.

The idea is a system that builds around Paper's data component API (so that we don't have to use the sketchy ItemMeta support for components), and manages things like the component properties, the different component states (removed, set, unset), the MaterialTag and ItemTag variants of component tags, etc.

This adds DataComponentAdapters that take both a Denizen type and an API type, and toDenizen/toPaper methods to be implemented.
Beyond that, it manages storing the Denizen propery name -> item component mapping (when they don't match), registering both the ItemTag property and the MaterialTag, and registering tags like ItemTag.is_overridden.
It also has utility methods like setIfValid (for setting elements from a map into a Paper builder class, which is going to be extremely common in these), and getComponentType for getting a component type by name or by Denizen property name.
It has a Property sub-class that's a generic implementation of an item property using the toDenizen/toPaper methods from DataComponentAdapter.

Also adds an ItemRemoved property that controls the item properties explicitly removed from the item.
Its setter is an addition-only setter (similarly to how NBT properties used to work, for example) - this works well for being a property, but might be a little confusing for script usage as you'd actually un-remove a component by unsetting it with the direct mechanism (e.g. adjust removed:food: remove it, adjust food unset it)? although the alternative would be manually clearing the components patch - idk, lmk what do you think.
ItemHelperImpl(1.21)#getRawComponentsPatch now excludes removed components when excludeHandled is true.

I implemented a FoodAdapter for the food component (both for testing and as an example).

This has a bunch of meta docs stuff - I tried writing a general explanation & examples for item components in DataComponentAdapter, and also adapters like FoodAdpater have a weird thing where they have both a MaterialTag meta and a property meta with the same return types - could potentially be a more integrated approach, but this is probably fine for now.

For registering adapters, I added a separate ComponentAdaptersRegistry that's called in PaperModule, as things were starting to get a little cramped in there - lmk if you'd prefer just having it all in PaperModule though.
I also added a separate package for component adapters as there wasn't really anywhere good to put them, com.denizenscript.denizen.paper.datacomponents.