Retire generate_king_moves()

We have only one call place so inline its content.
BTW, function is already declared as FORCE_INLINE.

Also some small refactoring while there.

No functional change.
Don't prefetch if not needed

Prefetch access to hash tables only in case we
have changed pawn or material hash keys.

No functional change.
Get rid of some locals in do_castle_move()

Rewrite the logic to get rid of kBefore and rBefore.

No functional change.
Rewrite do_null_move()

Use a more traditional approach, along the same lines
of do_move().

It is true that we copy more in do_null_move(), but we
save the work in undo_null_move(). Speed test shows the
new code to be even a bit faster.

No functional change.
Rewrite do_castle_move()

And handle the castle directly in do/undo_move().
This allow to greatly simplify the code.

Here the beast is the nasty Chess960 that is
really tricky to get it right because could be
that 'from' and 'to' squares are the same or
that king's 'to' square is rook's 'from' square.

Anyhow should work: verified on all Chess960
starting positions.

No functional and no speed change also in Chess960.
Revert "Extend full 3 fold detection to PvNodes"
Revert "Simplify Evaluation"

This reverts commit 496c7497cb81de4383
Restore "fail-low of reduced" and close regression

This reverts "Threat Extensions" and is the last of
this revert series.

In single-thread tests we should now be on par with 2.3.1
Retire history.h

And move the contents to movepick.cpp, where they are
mostly used.

Idea from DiscoCheck.

No functional change (bench 5379503)
Unify History and Gains under a single Stats class

Handling of History and Gains is almost the same, with
the exception of the update logic, so unify both
classes under a single Stats struct.

No functional change.
Correctly score enpassant captures

Surprisingly this rare case was not considered
when scoring a capture.

Also take in account that in the promotion case
we gain a new piece (typically a queen) but we
lose the promoting pawn.

These small issues were present since Glaurung times!

Found while browsing DiscoCheck sources

bench: 5400063
Rename prevents_move() to refutes()

Better! From DiscoCheck.

No functional change.
Templetize score_xxx() functions

So to be style-wise aligned with the corresponding
generate() functions.

No functional change.
Be clear about not LMR the ttMove

Currently a ttMove is reduced with ss->reduction = DEPTH_ZERO,
so it is actually not reduced (as it should be), but the
trick works just becuase it happens that ttMove is the first
to be tried and

reduction(depth, 1)

Always returns zero. So explicitly forbid reduction of ttMove
in the LMR condition. This is much clear and self-documented.

No functional change.
Some renaming in split()

Naming suggested by jundery.

No functional change.
Move split() under Thread

Previous renaming patch suggested this reformat:
when a better naming leads to a better code!

No functional change.
Derive ThreadPool from std::vector

Prefer sub-classing to composition in this case.

No functional change.
Slightly change split() API

This function "returns" two values: bestValue and bestMove

Instead of returning one and passing as pointer the other
be consistent and pass as pointers both.

No functional change.
Add const qualifer to check_is_dangerous

No functional change.
Rename posKey stored in the transposition table

[Edit: Slightly extended by me]

No functional change.