Cleanup VALUE_KNOWN_WIN conditions (8334443)

These conditions have been added randomly without any sign of understanding in this patch:
https://github.com/official-stockfish/Stockfish/commit/55a3e0af8d0d1e169cc8b16541ffeb41e157b66e. This pull request is essentially cleans up the mess.

**Futility Pruning in Child Node**

`abs(eval) < VALUE_KNOWN_WIN`: Absolute value is wrong here. A negative win/mate value is fine, because we are being more conservative. What is not fine is to fail high with "mate in 10" when it's a "mate in 20", but the opposite is fine (fail high with mated in 20 when it's mated in 10).

`abs(beta) < VALUE_MATE_IN_MAX_PLY` is a completely random addition that comes from nowhere. We don't care about the value of beta here. We care about the value that we will return `eval - margin`.

**Null Move Pruning**

Extend "do not return unproven mate scores" to "do not return unproven win scores", consistently with Futility Pruning. All we do here is fail hard (conservative) instead of fail soft when the nullValue is a win value (and a fortiori a mate value).

`abs(beta) < VALUE_KNOWN_WIN`: Again a completely random addition. We don't care about beta! We only care about nullValue which we are about to return.

**Singular Extension**

`abs(beta) < VALUE_KNOWN_WIN`. Again, added completely randomly without any logic behind. The singular search is done around ttValue not beta.

**Futility Pruning (Parent Node)**

Added the missing condition `futilityValue > -VALUE_KNOWN_WIN`, which is present in the `qsearch()` but has been forgotten here. It makes the parent/child node futility pruning consistent. What good is it to guard against false win scores in futility child node if you don't do it in the parent node? It can have the same effect.

**STC**
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14575 W: 3101 L: 2967 D: 8507

**LTC**
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42579 W: 7580 L: 7496 D: 27503