Don't use std::vector::data()

It is a C++11 only function.

Reported by Eelco.

No functional change.
Introduce Cut/All node definitions

Follow Don Dailey definition of cut/all node:

"If the previous node was a cut node, we consider this an ALL node.
The only exception is for PV nodes which are a special case of ALL nodes.
In the PVS framework, the first zero width window searched from a PV
node is by our definition a CUT node and if you have to do a re-search
then it is suddenly promoted to a PV nodes (as per PVS search) and only
then can the cut and all nodes swap positions. In other words, these
internal search failures can force the status of every node in the subtree
to swap if it propagates back to the last PV nodes."

http://talkchess.com/forum/viewtopic.php?topic_view=threads&p=519741&t=47577

With this definition we have an hit rate higher than 90% on:

    if (!PvNode && depth > 4 * ONE_PLY)
        dbg_hit_on_c(cutNode, (bestValue >= beta));

And an hit rate of just 28% on:

    if (!PvNode && depth > 4 * ONE_PLY)
        dbg_hit_on_c(!cutNode, (bestValue >= beta));

No functional change.
Reduce more CUT nodes

We got a good result from this tweak, in line with
what was already found by Don Dailey.

At short TC:
LLR: 2.95 (-2.94,2.94)
Total: 13097 W: 2742 L: 2598 D: 7757

At long TC:
LLR: 2.97 (-2.94,2.94)
Total: 7281 W: 1408 L: 1265 D: 4608

bench: 5108393
Reduce more CUT nodes only if parent node is reduced

So when we are doing a LMR search at the parent ALL node.

This patch didn't prove stronger at 60" TC
LLR: -2.97 (-2.94,2.94)
Total: 22398 W: 4070 L: 4060 D: 14268

But, first, it scores at 50%, second (and most important for me) the opposite,
i.e. normal reduction when parent node is not reduced, seems very bad:
LLR: -2.95 (-2.94,2.94)
Total: 7036 W: 1446 L: 1534 D: 4056

According to Don, this idea of increased reduction of CUT nodes
works because if parent node is reduced, missing a cut-off due to
reduced depth search (meaning position is somehow tricky) forces
a full depth research at parent node, giving due insight in this
set of sensible positions.

IOW if we expect a node to fail-high at depth n, then we assume it
should fail-high also at depth n-1, if this doesn't happen it means
position is tricky enough to deserve a research at depth n+1.

bench: 4687419
Fix description of TT entry

It was way outdated and wrong !

No functional change.
Revert "Reduce more CUT nodes only if parent node is reduced"

This reverts commit d54e8a59551a7ebcbf2c2155dce46c7386b1742a.

It was not proved with SPRT this tweak is stronger. So revert it
for now to follow fishtest guidelines.

bench: 5108393
Use move_pawns() in Pawns::probe

And rename some stuff.

No functional change.
Don't calculate pawnsOnSquares twice

And reformat some code while there.

No functional change.
Rename piece_count and piece_list

No functional change.
Remove redundant condition in probcut

When !ss->skipNullMove it is assured that excludedMove == MOVE_NONE

No functional change.
Merge some if statements in pos_is_ok()

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Remove confusing optimization

Here we skip the call to pos.attacks_from<ROOK>(s) in the 98%
of cases, testing the first 2 members first. Unfortunatly
code is a bit triky and not clear. So we give up to the
speed optimization in exchange of more code clarity.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Include file attacks in 'major on pawn'

Passed both short TC:
LLR: 2.97 (-2.94,2.94)
Total: 57846 W: 12248 L: 11974 D: 33624

And long one:
LLR: 2.95 (-2.94,2.94)
Total: 9181 W: 1732 L: 1581 D: 5868

bench: 4609948
Micro-optimize perft

Avoid to call perft function when we just need to count
moves, at leaf nodes.

Speed up of almost 2%

No functional change.
Name functions along corresponding UCI commands

No functional change.
Simplify hidden_checkers()

De-templetize and pass color as function argument.
No speed change.

No functional change.
Retire ThisAndAdjacentFilesBB[]

It is unused. Also renamed attack_span_mask to
pawn_attack_span

No functional change.
Retire in_front_bb(Color c, Square s) overload

Explciitly call rank_of() in the few places where
it is used.

No functional change.
Don't explicitize enum values when not needed

Compiler will chose the correct values in sequential
order for you.

Also move file and rank bitboards definitions to
bitboard.h

No functional change.
Move SquareDistance[] to bitboard.cpp

No functional change.