feat(config): Split thresholds into their own report types

[Synful-Syn]

!!! It contains config changes !!!
View the conf/Anticheat.conf.dist file to see the config changes.

Changes Proposed:

• There were alerts that did not mention what was the player being reported for. They should finally mention what was the report in question instead of just [ANTICHEAT ALERT]: [Awfulandterriblegnome] - Latency: 19 ms.
• Replace config Anticheat.AlertFrequency for Anticheat.AlertFrequency.Speed and every other report types.
• Replace config Anticheat.ReportinChat.Min for Anticheat.ReportInChatThreshold.Min.Speed and every other report types. It should had capitalized the "in" part of ReportinChat. It should had also specified that it was a threshold.
• Same with Anticheat.ReportinChat.Max.
• Remove Anticheat.ReportsForIngameWarnings for being redundant with Anticheat.ReportinChat.Min and max.
• Added GetReportNameFromReportType for getting a text equivalent of the current ReportTypes.
• Added BuildAndSendReportToIngameGameMasters. This will remove the need to type more code every time we wish to send an alert to the game masters.
• Added locale_frFR in acore_string.
• Corrected the spanish locales in acore_string. Thanks to @Nefertumm !
• Removed _alertFrequency (inherited from the just removed config Anticheat.AlertFrequency) and _counter as they were used as a total of reports instead of report specific for the purpose of alerting the game master.

Issues Addressed:

• Does not close Feature: anti pass through closed door cheat and separate different cheat numbers #84

Tests Performed:

• Reproduced that false positive until the message appeared and stopped appearing: [False positive] Jump report from using Blink above a pool of water on a flying mount #111

How to Test the Changes:

1. Have a game master with its game master mode disabled and with the config Anticheat.EnabledOnGmAccounts = 1 and start doing spooky cheat stuff.

Known Issues and TODO List:

• Remove COUNTER_MEASURES_REPORT from enum ReportTypes as it is not a hack.

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.