refactor(translations): front-facing message translations

[rumblefrog]

This moves a good majority of the front-facing messages to translations.

Motivation and Context

Allow ease of translations of hard-coded values. Also closes #582

How Has This Been Tested?

This has not been tested so far.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.

[CrazyHackGUT]

This is really good idea - move log messages to phrases and don't set obviously used language?
At this moment, your plugin can format log phrases on various languages if someone plugin used SetGlobalTransTarget(), and admin has translation to another languages.

[rumblefrog]

@CrazyHackGUT Not sure if I understand the phrasing, but are you proposing that I do set global translation target.

[CrazyHackGUT]

I propose use %T instead %t and LANG_SERVER (SourceMod define; targets to default SM locale (en; can be changed in core.cfg)) as client for log entries, for example.

[TheByKotik]

I propose use %T instead %t and LANG_SERVER (SourceMod define; targets to default SM locale (en; can be changed in core.cfg)) as client for log entries, for example.

No need that.
Both functions ( LogToFile() and LogAction() ) call this on C++ side.