Don't save stale value in TT after split

If we return from split with a stale value
due to a stop or a cutoff upstream occurred,
then we exit moves loop and save a stale value
in TT before returning search().

This patch, from Joona, fixes this.

bench: 8678654
Use only standard conforming eg_value()

Remove the optimization for Intel, is not
standard and can break at any time, moreover
our release build is not done with Intel C++
anymore so we don't need to sqeeze the extra
speed out from this compiler.

No functional change.
Revert to Galurung's KBPsK endgame

After reverting to the original Tord's
endgame, a search on position

7k/6p1/6B1/5K1P/8/8/8/8 w - - 0 1

Reports, correctly, a draw score instead of
an advantage for white.

Issue reported by Uri Blass.

bench: 8678654
Add stealmate detection to evaluation

Currently a stealmate position is misevaluated
in a negative/positive score, this leads qsearch(),
that does not detects stealmates too, to return the
wrong score and this yields to some kind of endgames
to be completely misevaluated.

With this patch is fully fixed follwing position

7k/6p1/6B1/5K1P/8/8/8/8 w - - 0 1

Also in SMP case.

Correct root cause analysys by Ronald de Man.

bench: 8678654
Fully correct stealmate detection

In the (rare) cases when the two conditions
are true, then fully check again with a slow
but correct MoveList<LEGAL>(pos).size().

This is able to detect false positives like
this one:

8/8/8/Q7/5k1p/5P2/4KP2/8 b - - 0 17

When we have a possible simple pawn push that
is not stored in attacks[] array. Because the
third condition triggers very rarely, even if
it is slow, it does not alters in a measurable
way the average speed of the engine.

bench: 8678654
Fix KXK endgame

Position is win also if strong side has a bishop
and a knight (plus other material, otherwise
KBNK would be triggered instead of KXK).

This fixes a subtle bug where a search on position

k7/8/8/8/8/P7/PB6/K7 b - - 6 1

Instead of returning a draw score, suddendly returns
a big score. This happens because at one point in
search we reach this position:

8/Pk6/8/8/8/4B3/P7/K7 w - - 3 8

Where white can promote. In case of rook promotion (and also in case of
queen promotion) the resutling position gets a huge static eval that is
above VALUE_KNOWN_WIN (from the point of view of white). So for rook
promotion it is

          &&  futilityBase > -VALUE_KNOWN_WIN

that prevents futility pruning in qsearch. (Removing this condition indeed
lets the problem occur). Raising the static eval for K+B+N+X v K to a value
higher than VALUE_KNOWN_WIN fixes this particular problem without having to
introduce an extra futility pruning condition in qsearch.

I just checked and it seems K+R v K, K+2B v K and even K+B+N v K already get
a huge static eval. Why not K+B+N+P v K?

I think this fix corrects an oversight. There is special code for KBNK, but
KBNXK is handled by KXK, so the test for sufficient material should also test
for B+N.

bench: 8678654
Revert back KBPsK to latest Gary's version

The bug was found to be elsewhere. This version
is correct and also is able to detect as draw
positions like:

8/8/5b2/8/8/4k1p1/6P1/5K2 b - - 6 133

bench: 8678654
Revert stalemate detection in evaluation

Unfortunatly we have a slow down that causes
a regression in STC with no-regression mode:

LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 22454 W: 3836 L: 4029 D: 14589

bench: 8678654
Revert dynamic contempt

On a final fixed game number test it failed
to prove better than standard version.

STC 15+0.05

ELO: -0.86 +-1.7 (95%) LOS: 15.8%
Total: 57578 W: 10070 L: 10213 D: 37295

bench: 8802105
Sync with master

bench: 8802105