Add a new localisation handling layer PG.StarWarsGame.Localisation

[gruenwaldlk]

The new layer PG.StarWarsGame.Localisation should accomplish the following goals:

• The layer enhances the raw DAT in-memory-representation with additional metadata.
• The layer allows for validation and handling of all official languages the engine can handle.
• The layer should still be open to be extended to handle languages the game engine does not support. Additional languages are up to other developers to support.
• The layer provides means to load and store common community formats, e.g. CSV as used by @ThrawnsRevenge or XML as used by @gruenwaldlk 's text editor in addition to loading from/storing to DAT files.
• The format support has to be extensible to accommodate other formats (TSV, ...) but only the most common formats will be provided for now.
• The layer provides at least an interface definition for a localisation repository that can be used for advanced handling of translations.
• The layer should still allow access to the "bare-metal" representation of the DAT file, but discourage its use.

[AnakinRaW]

For me the only requirement, not sure if that's already covered or not in the list above, is that it shall be possible to use custom serialization formats.

Also here is a grammar file which i think can be used to represent text files.

TextFile := LANGUAGE_SPEC (NEW_LINE TEXT_ENTRY)*
LANGUAGE_SPEC := 'LANGUAGE' '=' LANG_CODE
LANG_CODE := "[A-Z]+"
TEXT_ENTRY := TEXT_KEY ' ' TEXT_VALUE
TEXT_KEY := [A-Z]+
TEXT_VALUE := [Unicode Character]*
NEW_LINE: '\r\n'

[gruenwaldlk]

For me the only requirement, not sure if that's already covered or not in the list above, is that it shall be possible to use custom serialization formats.

That should be covered by The format support has to be extensible to accommodate other formats (TSV, ...)

I'm thinking of exposing an interface for a serializer and an format descriptor which is used by the layer and can be implemented by applications using the layer as well.
As long as those extensions are then registered as services, the factory should be able to pick them up and read/write the format.

[AnakinRaW]

fair enough. shall these formats get their own package?

[gruenwaldlk]

I planned on bundling at least a CSV type and maybe the XML format.
It would be more in line with .NET's approach to have a setup like My.Library.Abstractions and an additional implementation package which is great in theory, but I honestly don't exactly see there being many formats being added by anyone who not also has access to just directly bundling them.