Don't rely on Enum#ordinal() for serialization

[Trigary]

The enum declaration order should not be used as a serialization ID. A system was previously in place that supported hardcoded IDs instead of ordinals but was removed due to me not liking all that overhead in the codebase. The boilerplate code in these serializable enums should be abstracted away and this system should be readded.

At the time of creating this issue, there are five enums that need to be serialized. Two of these are in the backend subproject: PacketType and GuiElementType. These are the ones that previously supported this system, and it's easy to implement it again for them.

The other three enums are more complicated because they reside in the api subproject and are inner classes. This means that the client- and server-side might have to have its own, separate enum classes for these data entries or the enums have to be moved to the common subproject. I dislike this second idea because I believe that the quality of the API should be the top priority, and moving them to another subproject means that they can no longer be inner classes and would also expose implementation details that are irrelevant to the plugin developer. (This actually only holds true for ResizeMode, since both Anchor and Alignment define API-accessible "numpad number" IDs which are used for serialization.)

[Trigary]

ResizeMode has been removed, ignore what I said regarding it.

[yannicklamprecht]

The easy way would be to send the name instead. Other idea is to have a register mappings packet. Where you initially send an Enum.name <-> Enum.ordinal map.

What is your idea?

[Trigary]

Giving each enum value a hardcoded numerical ID.