Remove duplicate middle of screen alerts + mute some areas against some Z-Hack false positives

[Synful-Syn]

Remove duplicate messages in middle of the screen + remove lowest average from anticheat global command

Changes Proposed:

• Removes the duplicate message that appears at the middle of the screen alerting a countermeasure against a fly hacker even if you had the Anticheat.CM.ALERTSCREEN setting disabled.
• Same with jump hack
• Same with advanced jump hack
• Same with ignore-z hack
• Remove the "lowest average" section from the .anticheat global command. It is a silly thing to be seeking for.

Added the following areas to the excluded Ignore-Z hack detection.

• Gnomeregan, some corridor inside the instance, .go xyz -466.640076 260.263092 -208.009796
• Scarlet Monastery, armory, .go xyz 1744.680786 -364.786957 8.011654
• Shadow Labyrinth, boxes inside the instance, .go xyz -409.122559 -120.865135 15.713029
• Botanica, Laj's platform, .go xyz -204.576462 391.573334 -11.178043

Issues Addressed:

• Closes none, I haven't bothered making a bug report.

Tests Performed:

• To test if the messages still appear in the middle, I've reproducted [False positive] Jump report from using Blink above a pool of water on a flying mount #111
• Went to the locations I had added and tried to reproduce the Z-hack false positives.

How to Test the Changes:

1. Uhh... compare with an older commit!
2. Play with the Anticheat.CM.ALERTSCREEN setting!

Known Issues and TODO List:

• [ ]

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.