Profile Build with Hash=16

16MB for 1" searches is more comensurate with the average use case.

And 16 is the default used by stockfish bench, so it makes sense to be
consistent, if only to have the same minimum memory requirement for using
SF and compiling it with PGO.

No functional change.

Resolves #109
Use Depth instead of int in search

And make it more ONE_PLY value independent,
although we are not there yet.

No functional change.

Resolves #111
Use if/else instead of goto

Real men jump/branch by hand...but
we prefer the humble way.

Moved also some uci info code where it
belongs, while there.

No functional change.

Resolves #110
Use quiet ttMove in qsearch() (7962287)

Daniel Jose reported that it was an elo gain in his engine:
http://www.talkchess.com/forum/viewtopic.php?t=54290

STC: Hash=16
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 33067 W: 6670 L: 6571 D: 19826

LTC: Hash=64
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 41181 W: 7008 L: 6920 D: 27253

And another one to verify no regression with hash pressure:

STC: Hash=4
LLR: 2.96 (-2.94,2.94) [-4.00,0.00]
Total: 25085 W: 5059 L: 4991 D: 15035

Verified that qsearch does not explode after this patch (recapture threshold).

Bench 7962287

Resolves #112
100% accurate PV display

This gives SF accurate PVs, such that the evaluation of the leaf node in
the PV matches the score backed up to the root (99% of the time.
q-search will use the value stored in the hash table instead of the eval
value sometimes).

One drawback is that fail-high/low only get a minimal 2 move PV.

It doesn't add any additional overhead to the non-PV codepath except an
extra eight bytes to the SearchStack structure in multi-threaded
searches.

A core part of this is not pruning based on TT score in PV nodes. This
was measured as not being a regression at multiple TCs, except for one
exception, fast TC with huge hash, which is not realistic for longer
searches.

STC - 1 thread, 128 mb hash
ELO: 1.42 +-3.1 (95%) LOS: 81.9%
Total: 20000 W: 4078 L: 3996 D: 11926

STC - 3 thread, 128 mb hash
ELO: -3.60 +-2.9 (95%) LOS: 0.8%
Total: 20000 W: 3575 L: 3782 D: 12643

STC - 3 thread, 8 mb hash
ELO: 0.12 +-2.9 (95%) LOS: 53.3%
Total: 20000 W: 3654 L: 3647 D: 12699

LTC - 3 thread, 32mb hash
ELO: 2.29 +-2.0 (95%) LOS: 98.8%
Total: 35740 W: 5618 L: 5382 D: 24740

Bench: 6984058

Resolves #102
Use DEPTH_MAX instead of MAX_PLY

When comparing to a Depth it is more
consistent to use DEPTH_MAX instead
of a int.

This is a subtle difference because we use
ply and depth almost interchangably in SF,
but they are different. FOr counting plies
makes ense to continue using ints, while
for Depth we have our specific enum.

This cleanly fixes a new Clang 3.5 warning:

No functional change.
Half History Max

STC
LLR: 3.35 (-2.94,2.94) [-0.50,3.50]
Total: 17993 W: 3740 L: 3508 D: 10745

LTC
LLR: 3.25 (-2.94,2.94) [0.00,4.00]
Total: 21346 W: 3691 L: 3453 D: 14202

Bench: 7694316

Resolves #120
Clear token before reading from input

Previously token would keep its value from the previous line when an empty
line was input, leading to unexpected behaviour.

No functional change

Resolves #119
Use PHASE_MIDGAME in game_phase()

No functional change

Resolves #117
Fix a warning on Intel C++

warning #2259: non-pointer conversion from "int" to
"uint8_t={unsigned char}" may lose significant bits

No functional change.
Codying style in accurate PV

This is the first of a patch series to
rearrange and simplify accurate PV.

In this patch there is simple coding
style and reformatting stuff.

Verified with fishtest it does not crash
with MAX_PLY = 8

No functional change.
Fix fen output for castling rights

This is a regression from 428962a

We have to cast to char here, otherwise the compiler
interprets it as an integer, and writes a number.

No functional change

Resolves #122
Fix some comments

No functional change.

Resolves #123