Improve (Multiblock) Server Side Number Formatting

[warjort]

What:
In #1467 the client side number formatting was improved by adding %,d and %,f to the language file for numbers.
This was not possible for the serverside because TextComponentTranslatable doesn't support anything except the %s format.
This was recently mentioned here: Shadows-of-Fire/Shadows-of-Greg#151

How solved:
Implement an EnhancedTextComponentTranslatable that knows how to do all the formatting supported by java.util.Formatter

This enhanced version is not used directly, instead a subclass of the ITextComponent.Serializer automatically swaps the
normal TextComponentTranslatable for the enhanced version during deserialization on the client.
Additionally, it also tries to parse the arguments deserialzed as integers/floats - the default serializer serializes them using String.valueof() and on the client side it does a dance where it effectively does

String replacementObject = new TextComponentString(primitiveJson.asString()).getText();

The AdvancedTextWidget has been changed to use this new enhanced serializer.
This is used by Multiblock controllers amongst other things.

Outcome:
Multiblock displays can now use formats like %,d

Additional info:
To demonstrate the capability, I have changed the multiblock EU output in the lang file to use %,d see image.

I changed both the serialize and deserialize to use the enhanced version in AdvancedTextWidget.
This is just for symmetry. The change in behaviour is entirely in deserialize on the client.

Possible compatibility issue:
None expected. To enable this feature, the lang file will need to be updated to use something other than %s.

[warjort]

Issues:

1. The language file needs to be gone through again to see what other server side numbers can benefit from this change.

2. This is still not a complete solution to the problem. There are other uses of TextComponentTranslatable where we don't control the deserialization (e.g. TOP or chat messages) that can't take advantage of this change.

3. Issue (2) above could potentially be solved by using a CoreMod to swap all uses of ITextComponent.Serializer with this new Enhanced version.

4. This mechanism could be extended to other information. e.g. you can imagine a special escape character that lets you do something like:

new TextComponentTranslation("some.translation.key", itemStack);
some.translation.key=item: %q

to display an item description on the client. I haven't checked if %q is already used by java.util.Formatter