Don't blunder under extreme time pressure

We always attempt to keep at least this emergencyBaseTime
at clock. But if available time is very low it means that
we will force ourself to play immediately to satisfy the
emergencyBaseTime constrain and so leading to blunders.

Patch is good at short and very short TC (15secs and 5secs respectively)
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26590 W: 5426 L: 5245 D: 15919

LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5767 W: 1397 L: 1268 D: 3102

Instead seems has no influence at longer TC (60 secs)
LLR: -2.96 (-2.94,2.94) [0.00,6.00]
Total: 79862 W: 13623 L: 13339 D: 52900

So it is committed to have a broader testing but is
to be consider still EXPERIMENTAL and can be reverted
easily.

No functional change.
Fix operator++ definition

ENABLE_OPERATORS_ON has incorrect definitions of
post-increment and post-decrement operators.

In particularly the returned value is the variable
already incremented/decremented, while instead they
should return the variable _before_ inc/dec.

This has no real effect because are only used in loops
and where the returned value is never used, neverthless
it is wrong. The fix would be to copy the variable to a
dummy, then inc/dec the variable, then return the dummy.

So instead, rename to pre-increment that can be implemented
without the dummy, actually the current implementation
it is already the correct pre-increment, with the only change
to return a reference (an l-value) and not a copy, so
to properly mimic the pre-increment on native integers.

Spotted by Kojirion.

No functional change.
Use pre-increment also for native types

Now that we use pre-increment on enums, it
make sense, for code style uniformity, to
swith to pre-increment also for native types,
although there is no speed difference.

No functional change.
Nicer operator declerations

No functional change.
Code style at passed pawn eval

No functional change.
Rewrite unstoppable pawns evaluation

Instead of current code, give a bonus according to the frontmost
square among candidate + passed pawns.

This is a big simplification that removes a lot of accurate code
substituting it with a statistically based one using the common
'bonus' scheme, leaving to the search to sort out the details.

Results are equivalent but code is much less and, as an added bonus,
we now store candidates bitboard in pawns hash and allow this
info to be used in evaluation. This paves the way to possible
candidate pawns evaluations together with all the other pieces,
as we do for passed.

Patch passed short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 16927 W: 3462 L: 3308 D: 10157

Then failed (quite quickly) at long TC
LLR: -2.95 (-2.94,2.94) [0.00,6.00]
Total: 8451 W: 1386 L: 1448 D: 5617

But when ran with a conclusive 40K fixed games at 60 secs it proved
almost equivalent to original one.

ELO: 1.08 +-2.0 (95%) LOS: 85.8%
Total: 40000 W: 6739 L: 6615 D: 26646

bench: 3884003
Fix time parameters for blitz games

The ideal setting for super-blitz might be something like:

    "Emergency Base Time" = 50
    "Emergency Move Time" = 5

This would give a total emergency time buffer of:

    50 + 40 * 5 = 250 ms

This setup replaces the previous half cooked hack
"Don't blunder under extreme time pressure".

Test results are very good at super blitz, but keep good even
at 60 secs.

At 5+0.05
ELO: 24.30 +-2.4 (95%) LOS: 100.0%
Total: 37802 W: 10060 L: 7420 D: 20322

At 15+0.05
ELO: 13.41 +-2.9 (95%) LOS: 100.0%
Total: 22271 W: 4853 L: 3994 D: 13424

At 60+0.05
ELO: 5.30 +-3.2 (95%) LOS: 99.9%
Total: 16000 W: 2897 L: 2653 D: 10450

No functional change.
Fix a silly unstoppable eval bug

The logic is broken for black side because we get more bonus
for pawn in 7th rank than for pawn in 2nd rank!

Spotted by Reuven Peleg

bench:3884409
Increase Emergency Move Time to 10

Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05

ELO: 2.41 +-2.3 (95%) LOS: 98.1%
Total: 37222 W: 7843 L: 7585 D: 21794

No functional change.
Increase Emergency Move Time to 20

Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05

ELO: 2.61 +-2.2 (95%) LOS: 99.1%
Total: 39869 W: 8258 L: 7959 D: 23652

No functional change.
Final time management setup

This is an even safer setup proposed and tested
by Alexandre Meirelles.

Regression testing of 40K games at 10+0.05 show
result is stable both against current master:

ELO: -0.29 +-2.2 (95%) LOS: 39.7%
Total: 40000 W: 8010 L: 8043 D: 23947

and again original master (the one with smallest
time parameters):

ELO: 1.71 +-2.2 (95%) LOS: 93.8%
Total: 40000 W: 8325 L: 8128 D: 23547

Alexandre verified with LittleBlitzer time losses are
greately reduced with this setup:

Games Completed = 2100 of 3000 (Avg game length = 35.745 sec)

Settings = RR/128MB/15000ms+50ms/M 1000cp for 12 moves, D 150 moves/
Time = 39200 sec elapsed, 16800 sec remaining
 1.  Stockfish 190913             1091.5/2100    803-720-577      (L: m=313 t=1 i=0 a=406)    (D: r=278 i=91 f=136 s=8 a=64)    (tpm=212.5 d=14.75 nps=925427)
 2.  Houdini 2.0 w32              1008.5/2100    720-803-577      (L: m=250 t=299 i=0 a=254)    (D: r=278 i=91 f=136 s=8 a=64)    (tpm=204.1 d=12.04 nps=1326351)

No functional change.
Reduce negative quiets by ONE_PLY / 2

Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 3402 W: 708 L: 593 D: 2101

And long TC:
LLR: 2.93 (-2.94,2.94) [0.00,6.00]
Total: 23379 W: 3972 L: 3759 D: 15648

bench: 3529630
Replace -O3 with -fast for intel compiler

No functional change.
Update disabled warnings for Intel compiler

No functional change.
Use a per-thread array for generated moves

This greately reduces stack usage and is a
prerequisite for next patch.

Verified with 40K games both in single and SMP
case that there are no regressions.

No functional change.
Increase MAX_MOVES to 256

This should be enough for any legal position, even
the handcrafted ones, like the one presented by Reuven:

1Q5R/4Q1K1/B1Q5/B4Q2/N2Q4/pQ4Q1/pn2Q3/krQ4R w - -

Where currently we crash. This reverts the patch
0049d3f337b6f3a66a06503c of 8/4/2012 where stack
was shrinked due to crashes while in deep analysys.

No functional change.
Fix best move lookup bug

If the uci option 'Best Book Move' is set to true the lookup still
returns a move at random instead of the move with the highest
weight.

No functional change.
Simplify tte use condition

No functional change.
Simplify extensions

Unify extensions between PV and not PV nodes
and remove all but check extensions.

This is a simplification so tested at fixed number
of games where proved to not regress.

About 45k games at 15+0.05
ELO: 1.23 +-2.0 (95%) LOS: 88.5%
Total: 45643 W: 9107 L: 8946 D: 27590

About 45k games at 60+0.05
ELO: 1.07 +-1.8 (95%) LOS: 87.8%
Total: 46786 W: 7728 L: 7584 D: 31474

bench: 3172206
Revert "Use a per-thread array"

This reverts commit 800410eef1c0811 and instead increases
stack size.

I went through the old emails with Daylen that reported the
crash issue on Mac OS X and was fixed by 0049d3f337b6f3a66a0.

It was reported default stack size for a thread in Mac OS X is 8
megabytes while the patch that we are reverting allows to reduce
stack size at max of about 217KB, so the reason for the crash was
only marginal in MAX_MOVES value. On those emails Daylen also
hinted how to increase stack size for Mac OS X to 16MB.

So prefer to increase stack size to 16MB instad of re-inventing
the wheel and do our home grown stack as we did with the patch
that we are now reverting (it will remain anyhow in git history
for documentation purposes).

No functional change.