EnchantmentType - prepare for MC 1.21 custom enchantments

[ShaneBeee]

Description

This PR aims to prepare Skript for future changes with Enchantments.
Minecraft has moved enchantments to be data driven in 1.21.
This also means the ability to create custom enchantments.
This PR helps prepare Skript for that change by using the Bukkit registry rather than hard coding and using the specific fields.

Mojang is planning a 1.21 release for sometime this summer. I figured it would be best to prepare ourselves now.

NOTES:

• parsing will first attempt to grab from lang file
• if parsing fails from lang file, we move on to get from key from Registry (this allows for parsing custom enchantments)
• toString will first attempt to find the a name from the lang file (ex: "Curse of Vanishing 1")
• if that fails, will send the key for a vanilla enchantment (ex: "vanishing_curse") or the full namespace for custom enchants (ex: "my_thing:explosive")
• Static Enchantment related methods/fields have been moved to EnchantmentUtils

---

Target Minecraft Versions: 1.21+
Requirements: none
Related Issues: none

[APickledWalrus]

I might prefer to keep support for custom names for Minecraft-provided enchantments. That is, one could write minecraft:vanishing_curse or curse of vanishing. This would keep the process automated but allow us to provide support for the typical representation of an enchantment's name. I'm not a super big fan of just vanishing_curse or vanishing curse (i think requiring the namespace is better when not using a Skript-provided name alias)

[ShaneBeee]

I might prefer to keep support for custom names for Minecraft-provided enchantments. That is, one could write minecraft:vanishing_curse or curse of vanishing. This would keep the process automated but allow us to provide support for the typical representation of an enchantment's name. I'm not a super big fan of just vanishing_curse or vanishing curse (i think requiring the namespace is better when not using a Skript-provided name alias)

thats probably a good idea, for a little backwards compatibility too

[sovdeeth]

Seconding pickle
Always have the key-based names, but also allow custom names via .lang

[APickledWalrus]

Looks good. May be wise to wait on #6695 if that implementation can be used here instead.

[APickledWalrus]

We could also choose to store names for undefined enchantments in this map (e.g. the full namespaced key as done in toString)