NBT Component Serializer

[Codestech1]

Adds a support for serializing components as NBT Binary Tags.

Resolves #995

[Codestech1]

The serialization works now, but i need to clean it up, add backwards compatibility (old nbt), add javadocs and deserialization. But the hardest part with understanding how everything realted to this (in both adventure and Minecraft) is done.

[Codestech1]

Component deserialization works properly (tested with a large component with many children and styling), component serialization however doesn't serialize lists of components (children, etc.) as anything else than compounds. I'll check if there's a way to make it check if all types of components can be serialized as a string without looping through the entire list twice (one time for checks, second time for creating the list).

What's left (let me know if i forgot anything):

• JUnit tests
• Services (for custom serializer imlementation, like the gson serializer)
• Cleanup (maybe split the serialization process to more classes?)
• More serializer options
• Make sure that legacy tags in hover event are serialized properly (I can't do it now, because i cannot even make them work through a /tellraw command in Minecraft)
• Javadocs

[Codestech1]

Another TODO:
The hover event serializer should serialize legacy show achievement hover events with value key instead of contents key

[Codestech1]

I forgot to add tests for hover event and click event, i'm adding them right now

[Codestech1]

Ok, it's ready now, i think

[zml2008]

please review what the game actually does, you've dragged over so much legacy baggage that'd be completely unnecessary if you actually thought things through

[Codestech1]

I've added a possibility to (de)-serialize a style without a component, because it's useful for new chat type registry in Minecraft. For example Minestom uses adventure styles to (de)-serialize the chat type styles.

[Codestech1]

After ~ 3 months i can say that it's stable. I've not noticed any issues with the serializer. I was using it in my server software - Jet - for that time. I tested all functionality, including item data components etc.

[kezz]

Generally speaking I'm happy with this. My only slight concern is that there's a lot of unchecked casts. I do wonder if we might be better off handling all of these and throwing nicer error messages (e.g. Expected <tag> to be of type Byte, was String)?

I don't think this is a blocker on a merge though, happy for this to go through and leave an issue for us to come back to that later.

[Codestech1]

Generally speaking I'm happy with this. My only slight concern is that there's a lot of unchecked casts. I do wonder if we might be better off handling all of these and throwing nicer error messages (e.g. Expected <tag> to be of type Byte, was String)?

I don't think this is a blocker on a merge though, happy for this to go through and leave an issue for us to come back to that later.

Yeah, but in my opinion that should be done in adventure nbt instead.

[kezz]

How could that be done in adventure-nbt?

[Codestech1]

How could that be done in adventure-nbt?

Making method such as asStringOrThrow would be useful.

[kezz]

I don't think that makes sense for an API.