Fix a subtle bug in UCI options printing

We want all the UCI options are printed in the order in which are
assigned, so we use an index that, depending on Options.size(),
increases after each option is added to the map. The problem is
that, for instance, in the first assignment:

o["Write Debug Log"] = Option(false, on_logger);

Options.size() can value 0 or 1 according if the l-value (that
increments the size) has been evaluated after or before the
r-value (that uses the size value).

The culprit is that assignment operator in C++ is not a
sequence point:

http://en.wikipedia.org/wiki/Sequence_point

(Note: to be nitpick here we actually use std::map::operator=()
 that being a function can evaluate its arguments in any order)

So there is no guarantee on what term is evaluated first and
behavior is undefined by standard in this case. The net result
is that in case r-value is evaluated after l-value the last
idx is not size() - 1, but size() and in the printing loop
we miss the last option!

Bug was there since ages but only recently has been exposed by
the removal of UCI_Analyze option so that the last one becomes
UCI_Chess960 and when it is missing engine cannot play anymore
Chess960.

The fix is trivial (although a bit hacky): just increase the
last loop index.

Reported by Eric Mullins that found it on an ARM and MIPS
platforms with gcc 4.7

No functional change.
Retire operator|(File f, Rank r)

Use make_square() instead. Less fancy but
more clear.

No functional change.
Trivial formatting in ucioption.cpp

No functional change.
Rename score to value in ExtMove

We use 'score' for the value mid-endgame pair.

No functional change.
Refresh TT entries generation automatically on probe

And other assorted simplifications, tested with SPRT[-3, 1]

Passed both short TC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 18814 W: 3600 L: 3475 D: 11739

And long TC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20731 W: 3217 L: 3096 D: 14418

No functional change.
Retire last usage of operator|(File f, Rank r)

This for some reason was missed.

No functional change.
Fix an incorrect 'friend' declaration

Spotted by Lee David.

No functional change.
Introduce penalty for weak (=unsupported) pawns.

We add a penalty for each pawn which is not protected by another pawn
of the same color.

Passed both short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 12107 W: 2411 L: 2272 D: 7424

And long TC
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 9204 W: 1605 L: 1458 D: 6141

bench: 7682173
Simplify TT replace strategy

Tested for no-regression with SPRT[-3, 1] at STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32046 W: 6020 L: 5918 D: 20108

No functional change.
Fix a bug in pawns eval tracing

Instead of totals we were showing white and
black values.

Spotted by Sven Schüle

No functional change.
Pinned pieces affect king safety

Here the new idea is to link pinned pieces
with king safety.

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 10047 W: 1867 L: 1737 D: 6443

And LTC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 10419 W: 1692 L: 1543 D: 7184

bench: 8325087
Restore old aspiration window to 16

Tested directly at LTC because previous long
test series on this topic shows it is TC dependant.

Tested with no-regression mode because gets rid of
an ugly and ad-hoc rule.

Test at LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 67918 W: 10590 L: 10541 D: 46787

bench: 7926803
Further simplification of TT replace strategy

No functional change
Raise VALUE_INFINITE

In some legal positions like this one:
R6R/3Q4/1Q4Q1/4Q3/2Q4Q/Q4Q2/Np1Q4/kB1N1KB1  b -- 0 1

We can have a very high score, in this case 30177 and 29267
for midgame and endgame respectively, and because
VALUE_INFINITE = 30001 we have an assert in interpolate()

Midgame and endgame scores are stored in 16 bit signed integers
so we can rise VALUE_INFINITE a little bit. This does not fix
the possibility of overflow in general case, just makes the
condition more difficult to trigger and anyhow better uses all
the score width.

Raising VALUE_INFINITE to 32000 seems to fix the problem for this
particular case.

No functional change.
Show evaluation from white POV in trace

We chose this instead of negamax sign convention
(ie. from the point of view of the side to move)
because it is more in line to how the eval
table is presented.

Also some tweak to formatting while there.

No functional change.
Fix a warning with MSVC 2010

Warning C4804: '<' : unsafe use of type 'bool' in operation

No functional change.
Fix a compile error with Intel C++

Error: a value of type "int" cannot be assigned
to an entity of type "Value"

No functional change.
Do not workaround function argument evaluation

Rewrite options initialization to do not trying to
hack upon the undefined evaluation order of function
arguments.

No functional change.
Drop not defended by pawn condition

Passed no-regression test both at STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 96554 W: 17563 L: 17572 D: 61419

and at LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 31891 W: 4905 L: 4801 D: 22185

bench: 7720896
Make operator<< to return void

This should help preventing misuse.

No functional change.