Interfaceification fixes

[tal5]

Changes

• Changed usages of valueOf, asEnum, etc. with old enums to LegacyNamingHelper#convert.
• Changed uses of #name/toString, the ElementTag enum constructor, etc. with old enums to String#valueOf (since it doesn't contain any explicit method calls on the instance, it doesn't blow up about having the wrong invoke instructions on old versions).
• Changed usages of Mechanism#requireEnum with old enums to LegacyNamingHelper#requireType.
• VillagerChangesProfessionScriptEvent: enum constructor in getContext (unrelated cleanup).
• Renamed EntityColor#listForEnum to listTypes, and changed it to take a class for the type instead of an enum array, and get the types list from the registry with Utilities#registryKeys for no-longer-enum types.
• server.map_cursor_types now uses different registry-based logic on 1.20+.
• server.structures now uses the new Utilities#registryKeys.

Additions

• LegacyNamingHelper#convert - takes in a class and string, and converts that string to the type of the class with either registries or enum conversions.
• LegacyNamingHelper#requireType - Mechanism#requireEnum but for no-longer-enums.
• Utilities#registryKeys - returns a ListTag of a registry's keys.

Note

Used an Optional for LegacyNamingHelper#requireType, since it just seemed like a good place to use it and have slightly cleaner & maybe faster code using it, with the alternatives being

if (mechanism.matches("profession") && LegacyNamingHelper.matches(Villager.Profession.class, mechanism.getValue().asString())) {
    setProfession(LegacyNamingHelper.convet(Villager.Profession.class, mechanism.getValue().asString()));
}

or

if (mechanism.matches("profession")) {
    Villager.Profession profession = LegacyNamingHelper.requireType(mechanism, Villager.Profession.class);
    if (profession != null) {
        setProfession(profession);
    }
}

Which are messier, especially when there's a bunch, I.e. in EntityColor (and since this is a temporary thing till 1.21 is the min version anyway) - let me know if you'd still prefer one of the other approaches though.

Note

Some of these technically have registries on all supported versions, but can't really cleanly make them use these as it'd still involve method calls on interfaces that are enums in older versions - can have a separate set of utils for handling registry stuff in mechs/tags which'll probably be needed anyway as more stuff move to registries, but that's for a different PR.