Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.

[vondele]

Fixes #2533, fixes #2543, fixes #2423.

the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.

This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular

no alse mates are announced with the poisened hash testcase

position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame

mates are found with the testcases reported in #2543

position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame

and

position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame

furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted

Analyzing 6566 mate positions for best and found mates:

                 ----------------best ---------------found
           nodes master revert  fixed master revert  fixed
        16000000   4233   4236   4235   5200   5201   5199
        32000000   4583   4585   4585   5417   5424   5418
        64000000   4852   4853   4855   5575   5584   5579
       128000000   5071   5068   5066   5710   5720   5716
       256000000   5280   5282   5279   5819   5827   5826
       512000000   5471   5468   5468   5919   5935   5932

On a testcase with TB enabled, progress is made consistently, contrary
to master

setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame

The PR (prior to a rewrite for clarity)

passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15

passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63

The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.

One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.

Bench: 4932981

[snicolet]

If there is no speed difference -- measured for instance in a long bench--, then we could remove the comment and move the VALUE_NONE case at the top to make the function more symmetrical?

if (v == VALUE_NONE)
    return VALUE_NONE;

if (v >= VALUE_TB_WIN_IN_MAX_PLY)  // TB win or better
 { 
   ...
 }

[vondele]

I can't measure any speed benefit, even though it is 3 vs 2 branches, so I'll merge the clearer looking code.