Introduce distance() and unify some API

Original work by Lucas.

No functional change.
Assorted code-style triviality

No functional change.
Retire pvMove in search()

Now we can directly replace it with
the definition resulting in simpler
and possibly faster code because
PvNode is evaluated at compile time.

No functional change.
Fix bounds of FutilityMoveCounts

This is a left-over from ONE_PLY == 2.

No functional change.

Resolves #107
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