Remove unuseful optimization in RKISS

Don't need a struct here. Speed test shows
result is teh same. Moreover RKISS is used
mainly at startup to compute magics, so
prefer to keep it simple...RKISS ;-)

Also some assorted triviality while there.

No functional change.
Improve KBPsK endgame

Better endgame with bishop and blocked g-pawn

bench: 8279065
Add some knowledge for KRPKB endgame

bench: 8279065
Add helper function verify_material

Allows to remove a lot of assert code in endgames.

No functional change.
Massive stronger/weaker renming

No functional change.
Remove a drawing rule from KBPsK function

The rule can be incorrect if the attacking king is
well placed e.g. 8/6K1/8/8/7k/1B6/7P/8 w - - 0 1

bench: 8279065
Double king safety weights

Good both at short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 5448 W: 1133 L: 1012 D: 3303

And at long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 40509 W: 6836 L: 6541 D: 27132

bench: 7700683
Bug fix for KQKRPs endgame

This lost position 8/8/3q4/8/5k2/2P1R3/2K2P2/8 w - - 0 1
was previously evaluated as a draw.

The king and rook need to be correctly placed with
respect to the _same_ pawn.

(Note also that the check for the pawn being on RANK_2
in the old version is redundant: it must be on RANK_2 if
it hopes to protect a rook on RANK_3)

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Simplification of KPsK function

Also the drawing criteria has been slightly loosened.
It now detects a draw if the king is ahead of all the
pawns and on the same file or the adjacent file.

bench: 7700683
Score chain pawn also by rank

Use the (rescaled) CandidatePassed[] table
that is already rank based.

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 11048 W: 2272 L: 2135 D: 6641

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 4116 W: 769 L: 645 D: 2702

bench: 8440524
Some evaluation code reshuffle

No functional change.
Further increase safe checks bonus

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 10466 W: 2087 L: 1953 D: 6426

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 26334 W: 4540 L: 4310 D: 17484

And also proved stronger than a slightly
different patch, also succesful against master:

https://github.com/mcostalba/Stockfish/commit/dc6830a3b4ed12

But losing against current one in a match
at 60secs with SPRT [-3, 3]:

LLR: -2.96 (-2.94,2.94) [-3.00,3.00]
Total: 44484 W: 7360 L: 7463 D: 29661

bench: 9160831
Revert "Further increase safe checks bonus"

This reverts commit 4bc2374450e30101392 for
two reasons.

First regression testing shows almost equal
score:

Before the patch:
ELO: 49.75 +-2.5 (95%) LOS: 100.0%
Total: 27205 W: 7113 L: 3244 D: 16848

After the patch:
ELO: 48.87 +-2.9 (95%) LOS: 100.0%
Total: 20860 W: 5478 L: 2563 D: 12819

Second, and more sensible to me, this patch
increases safe check bonuses to 4 times their
original value (!) and considering:

- Values were already well tuned

- Values are highly critical

- King safety is highly critical, very TC
  dependent and very difficult to test

- Our testing coverage is partial (self-testing,
  blitz times)

I think is better to be safe than sorry and so
I revert the patch.

bench: 8440524
Fix build on Intel compiler

Due to a strange issue (bug?) the ternary
operator does not return a BitCountType for
icc, so revert to the expression.

The same patch was already applied in
9749f1f14c956133c2f42f96592b

Thanks to NssY Wanyonyi for pointing out
this.

No functional change.
Fix pos.count<ALL_PIECES>()

It was never updated !

Currently it only affects evaluate_passed_pawns()
and in particularly the rule to increase the bonus
if we have more non-pawn pieces. We could simply use
popcount() instead and avoid the little slowdown
in put_piece() and remove_piece(), but this would
leave a very subtle and tricky hole where people
are forced to remember that pos.count<ALL_PIECES>()
does not work. This is not obvious and so dangerous.

Thanks to Ronald de Man for spotting this.

bench: 7931424
Further improve chain pawn evaluation

Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 28299 W: 5854 L: 5667 D: 16778

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 9738 W: 1797 L: 1644 D: 6297

bench: 9294116
Restore behaviour after count<ALL_PIECES> fix

Because pos.count<ALL_PIECES>(Us) was always zero,
rewrite the formula as if this would still be
the case.

bench: 8510004
Re-add "Further increase safe checks bonus"

After 40K games at 60 secs, result is still
not clear, but not a regression against SF 4

After
ELO: 50.11 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 10547 L: 4817 D: 24636

Before
ELO: 49.51 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 10483 L: 4821 D: 24696

So re-apply the patch to avoid to
special-case this one.

bench: 7403882
Tweak again chain pawn bonus

This is the first chain bonus version
from Ralph that also passed both

Short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 23460 W: 4727 L: 4556 D: 14177

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 31858 W: 5497 L: 5240 D: 21121

And performed better against current
committed version, always at 60secs:

LLR: -2.94 (-2.94,2.94) [-3.00,3.00]
Total: 26301 W: 4477 L: 4580 D: 17244

This test was done by Leonid.

bench: 8455956
Simplify futility margins formula

New formula mathces the old formula until d = 45

Test code:

int main() {

  for(int d=1; d<=45; d++)
  {
     int a = int(log(double(d * d) / 2) / log(2.0) + 1.001);
     int b = int(2.9 * log(double(d)));

     if (a != b) std::cout << d << std::endl;
  }

  return 0;
}

bench: 8455956