More aggressive post-futility pruning
Fix potential overflow
Fix cpu_count() on some platforms

When we use sysconf(_SC_NPROCESSORS_ONLN) to get number of
cores, we have to include sysconf library that is unistd.h

Sometimes it happens to work just becuase unistd.h indirectly
included by some other libraries, but not always.

Reported and fixed by Eyal BD

No functional change.
Merge Joona's increased static null pruning

The idea is to fail high more easily in static
null test if in the parent node we are already
very deep in the move list, so the propability
to fail high there is very low.

[edit: I have slightly changed the functionality
moving

ss->futilityMoveCount = moveCount;

At the end of the pruning code, this should not affect
ELO in anyway, but makes code more natural and logic]

Test with SPRT is good at 15+0.05
LLR: 2.96 (-2.94,2.94)
Total: 50653 W: 10024 L: 9780 D: 30849

And at 60+0.05
LLR: 2.97 (-2.94,2.94)
Total: 40799 W: 7227 L: 6921 D: 26651

bench: 4530093
Increase rook/queen on 7th bonus

Shows an increase at 15+0.05
LLR: 3.01 (-2.94,2.94)
Total: 20450 W: 4091 L: 3927 D: 12432

And at 60+0.05
LLR: 2.97 (-2.94,2.94)
Total: 61432 W: 10849 L: 10441 D: 40142

bench: 4493356

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Expose EvalInfo struct to search

Allow to use EvalInfo struct, populated by
evaluation(), in search.

In particular we allocate Eval::Info on the stack
and pass a pointer to this to evaluate().

Also add to Search::Stack a pointer to Eval::Info,
this allows to reference eval info of previous/next
nodes.

WARNING: Eval::Info is NOT initialized and is populated
by evaluate(), only if the latter is called, and this
does not happen in all the code paths, so care should be
taken when accessing this struct.

No functional change.
Store Eval::Info in Search::Stack

Instead of a pointer. This should fix the issue of
remaining with a stale pointer when for instance calling
IID, but also null search verification, singular search
and razoring where we call search with the same ss
pointer. In this case ss->ei is overwritten in the
search() call and upon returning remains stale.

This patch could have a performance hit because Eval::Info
is big (176 bytes) and during splitting we copy 4 ss entries.

On the good side, this patch is a clean solution.

Proposed by Gary.

No functional change.
Fix a crash introduced few days ago

Crash is due to uninitialized ss->futilityMoveCount that
when happens to be negative, yields to an out of range
access in futility_margin().

Bug is subtle because it shows itself only in SMP case.
Indeed in single thread mode we only use the

Stack ss[MAX_PLY_PLUS_2];

Allocated at the begin of id_loop() and due to pure
(bad) luck, it happens that for all the MAX_PLY_PLUS_2
elements, ss[i].futilityMoveCount >= 0

Note that the patch does not prevent futilityMoveCount
to be overwritten after, for instance singular search
or null verification, but to keep things readable and
because the effect is almost unmeasurable, we here
prefer a slightly incorrect but simpler patch.

bench: 4311634