LegacyComponentSerializer does not deserialize components properly if formatting code char is capitalized

[pop4959]

Related: https://github.com/EssentialsX/Essentials/pull/5710

As referenced, this is unfortunately common and recognized usage, color codes chars should be case-insensitive ideally.

Example component output from the deserializer without normalization using Essentials /nick to trigger the issue:

/nick &epop4959

TextComponentImpl{content="pop4959", style=StyleImpl{obfuscated=not_set, bold=not_set, strikethrough=not_set, underlined=not_set, italic=not_set, color=NamedTextColor{name="yellow", value="#ffff55"}, clickEvent=null, hoverEvent=null, insertion=null, font=null}

/nick &Epop4959

TextComponentImpl{content="§Epop4959", style=StyleImpl{obfuscated=not_set, bold=not_set, strikethrough=not_set, underlined=not_set, italic=not_set, color=null, clickEvent=null, hoverEvent=null, insertion=null, font=null}, children=[]}

[kezz]

Do capital letters after section signs render in the client? If not, then this isn't a bug report and something that can already be achieved by modifying the serializer using the builder to set additional formats.

[pop4959]

I quickly tested this (in a lazy way, so if you don't trust the method feel free to double check) - sending a custom brand packet which if I recall correctly the client only supports Legacy in. I tried §etest and §Etest which both appear as "test" in yellow on the vanilla client. So I believe this is indeed a bug.

Also noted on the additional formats, should have probably checked that before coming up with my other solution.

[kezz]

Yep, I can test and confirm that capitalisation doesn't matter so this is indeed a bug!

[pop4959]

Thanks, also applied your suggested fix to Essentials and it appears to work beautifully. Should hold us over until it gets addressed over here.