Add support for MMOItems

[vincenzopio]

This pull request introduces major enhancements to SmartSpawner's support for custom items, especially MMOItems integration, and improves how item spawners are identified, displayed, and priced. It enables referencing MMOItems in spawner configurations, allows custom pricing for plugin-owned items, and ensures spawner GUIs and holograms show the correct item names and icons. The changes also refactor the price GUI to handle both vanilla and custom items seamlessly.

Custom Item Integration and Identification

• MMOItems can now be used as spawner drops and as item spawners by referencing them with mmoitems:TYPE:ID in configuration files. The spawner will use the MMOItem's name, icon, and display item.
• Item spawners are now identified by their configured name rather than just their base material, preventing unintended stacking and allowing for unique styling per spawner.

Custom Pricing and Price GUI

• Items owned by other plugins can be assigned custom sell prices in sell_integration.yml, keyed by their reference string (e.g., "mmoitems:MATERIAL:RUBY": 250.0). These prices override shop-derived prices. The price GUI and backend now handle both vanilla and plugin items, displaying the correct icon and name for each. [1] [2] [3] [4] [5]

Display and Hologram Improvements

• Holograms and GUIs now use the correct item name and icon for custom items, using the new SpawnerDisplayName utility. This ensures that item spawner holograms display the proper MMOItem or plugin-owned item name and icon. [1] [2] [3] [4] [5] [6] [7] [8] [9]

Integration Infrastructure

• Added compile-time dependencies on mmoitems and mythiclib and implemented an extensible CustomItemRegistry with an MMOItems provider, allowing for future plugin integrations. [1] [2] [3] [4] [5] [6]

Configuration and Editor Enhancements

• The loot editor now correctly serializes plugin-owned items by storing their plugin reference string, ensuring accurate round-tripping and display in the configuration and GUIs.

These changes provide robust support for custom item plugins, improve user experience with more accurate displays, and allow for granular configuration and pricing of both vanilla and custom items.

[Nighterezi]

@vincenzopio Went through this end to end and it's in good shape. The provider abstraction is clean and leaves room for other item plugins later. A couple of things worth looking at before merge:

• Item spawner name resolution in the storage live-update path. SpawnerDisplayName.ofItem clones the template and reads getItemMeta() on every call, including for plain vanilla item spawners. The old path was just getVanillaItemName(material), which is a cached string lookup. This matters because createStorageSpawnerInfoButton rebuilds the info button on every batched redraw while someone has the storage GUI open, so for item spawners we now do a clone + meta read per tick where we used to hit a cache.
• Since the template is already a snapshot taken at config load (we never query MMOItems live at display time, that's why /ss reload is needed after /mmoitems reload), we can just resolve the display name once in parseConfig() and store it on ItemDefinition. It gets rebuilt with the template on every reload, so no new staleness, and the hot path drops back to reading a plain string.

[Nighterezi]

One thing I couldn't verify from reading alone is MMOItems display names with color codes go through getItemDisplayNameText (legacy section serialize) and then the placeholder layer, so I'd want a confirmation from you that colored names render cleanly in game and that selling an MMOItems item pays out the configured reference price