Speed up move generation

Pass the color as template parameter
to generate_all()

Speedup of 1,3% in perft and 2,5% in bench !

No functional change.
Small renaming

No functional change.
Tidy up Position::pretty

No functional change.
Fix a race at thread creation

At thread creation start_routine() is called
and from there the virtual function idle_loop()
because we do this inside Thread c'tor, where the
virtual mechanism is disabled, it could happen that
the base class idle_loop() is called instead.

The issue happens with TimerThread and MainThread
where, at launch, start_routine calls
Thread::idle_loop instead of the derived ones.

Normally this bug is hidden because c'tor finishes
before start_routine() is actually called in the
just created execution thread, but on some platforms
and in some cases this is not guaranteed and the
engine hangs.

Reported by Ted Wong on talkchess

No functional change.
Rework Thread hierarchy

Introduce ThreadBase struct that is search
agnostic and just handles low level stuff,
and derive all the other specialized classes
form here.

In particular TimerThread does not hinerits
anymore all the search related stuff from Thread.

Also some renaming while there.

Suggested by Steven Edwards

No functional change.
Factor out pieceList updating code

The new Position methods add_piece, move_piece, and remove_piece
now manage the member variables pieceList, pieceCount, and index,
and 9 blocks of code in Position that used to manipulate those
data structures by hand now call the new methods.

There is a slightly slowdown (< 1%) on Clang and on perft,
but the cleanup compensates the little speed loss.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Further factor out position update code

Along the lines of previous patch.

No functional change
Retire cpu_count()

Set threads number always to 1 at startup and let the
user explicitly to chose the number of threads.

Also preserve the useful behavior of automatically set
"Min Split Depth" according to the requested threads,
indeed this parameter is too technical for a casual user,
so, when left to zero, we set it on a sensible value.

No functional change
Refactor do_castle()

Not a real functional change, but bench changed due to different piecelist
reordering. To verify it a temporary my canonicalize_rooks function was
written as follows. It just ensures that the rook on the "smaller" square
is listed first.

void Position::canonicalize_rooks(Color c)
{
   if (pieceCount[c][ROOK] == 2)
   {
      Square s0 = pieceList[c][ROOK][0];
      Square s1 = pieceList[c][ROOK][1];
      if (s0 > s1)
      {
         pieceList[c][ROOK][0] = s1;
         pieceList[c][ROOK][1] = s0;
         index[s0] = 1;
         index[s1] = 0;
      }
   }
}

With this both bench and the test on Chess960 positions

./stockfish bench 128 1 8 Chess960.epd file > /dev/null

Gives same result.

bench: 4424151
Update polyglot.ini with new "Min Split Depth" default

No functional change.
Streamline time computation

No functional change.
Rewrite flip() to use FEN string manipulation

Instead of dealing directly with internal parameters
just "flip" the FEN string and set the position from
that.

No functional change.
Further tweak Position::flip

No functional change.
Increase LMR when not improving

Apply to LMR the same Eelco's idea
applied to move count pruning.

This is the result of a series of
attempts started by Thomas Kolarik.

Passed both short TC
LLR: 2.95 (-2.94, 2.94)
Total: 5675 W: 1241 L: 1117 D: 3317


And long TC:
LLR: 2.95 (-2.94, 2.94)
Total: 8748 W: 1689 L: 1539 D: 5520

bench: 4356801
Fix 'improving' condition

Because VALUE_NONE is 30002, it happens that
after a check the next move is never an improving
one.

After this patch bench signature is independent from
VALUE_NONE actual value.

bench: 4303194