Retire #ifdef SYZYGY macro

It just clutters the code for no
real reason.

No functional change.

Resolves #139
Rewrite TBScore in uci_pv()

Streamline the code and make
it understandable.

No functional change.

Resolves #135
Cleaning Syzygy profiling data

Updating the makefile so that the clean and gcc-profile-clean targets also
remove the profiling data files in the syzygy directory.

No functional change.

Resolves #136
Remove CONNECTED_KINGS from Syzygy code

No functional change

Resolves #140
Retire total_piece_count()

We really don't need to uglify in this way
our nice count() API with this ad-hoc hack.

So remove the hack and use the already
existing infrastructure.

No functional change.

Resolves #134
Retire hackish support for aCC and HP-UX from Makefile

- It is out of scope of the project.
- We have no way to verify that it even works anymore

No functional change

Resolves #142
Retire support for Haiku installation directory from Makefile

- It is out of the scope of the project.
- It is the responsibility of Haiku package maintainer to
  configure this.

No functional change

Resolves #143
Refactor syzygy code in search

Move to SF coding style.

Also skip calculating piece count in search()
when TB are not found (!TBCardinality)

No functional change.
Move TB stuff under Tablebases namespace

Simplified also some logic while there.

TBLargest needs renaming too, but itis for
a future patch because touches also syzygy
directory stuff.

No functional change.
Explicitly pass RootMoves to TB probes

Currently Search::RootMoves is accessed and even
modified by TB probing functions in a hidden
and sneaky way.

This is bad practice and makes the code tricky.
Instead explicily pass the vector as function
argument so to clarify that the vector is modified
inside the functions.

No functional change.
Rename some variables for more clarity.

No functional change.

Resolves #131
Add some tablebase positions to bench

This makes it easier to check for regressions in the tablebase code.

Bench: 9489202
5-man bench: 8943906

Resolves #145
Simpler PRNG and faster magics search

This patch replaces RKISS by a simpler and faster PRNG, xorshift64* proposed
by S. Vigna (2014). It is extremely simple, has a large enough period for
Stockfish's needs (2^64), requires no warming-up (allowing such code to be
removed), and offers slightly better randomness than MT19937.

Paper: http://xorshift.di.unimi.it/
Reference source code (public domain):
http://xorshift.di.unimi.it/xorshift64star.c

The patch also simplifies how init_magics() searches for magics:

- Old logic: seed the PRNG always with the same seed,
  then use optimized bit rotations to tailor the RNG sequence per rank.

- New logic: seed the PRNG with an optimized seed per rank.

This has two advantages:
1. Less code and less computation to perform during magics search (not ROTL).
2. More choices for random sequence tuning. The old logic only let us choose
from 4096 bit rotation pairs. With the new one, we can look for the best seeds
among 2^64 values. Indeed, the set of seeds[][] provided in the patch reduces
the effort needed to find the magics:

64-bit SF:
Old logic -> 5,783,789 rand64() calls needed to find the magics
New logic -> 4,420,086 calls

32-bit SF:
Old logic -> 2,175,518 calls
New logic -> 1,895,955 calls

In the 64-bit case, init_magics() take 25 ms less to complete (Intel Core i5).

Finally, when playing with strength handicap, non-determinism is achieved
by setting the seed of the static RNG only once. Afterwards, there is no need
to skip output values.

The bench only changes because the Zobrist keys are now different (since they
are random numbers straight out of the PRNG).

The RNG seed has been carefully chosen so that the
resulting Zobrist keys are particularly well-behaved:

1. All triplets of XORed keys are unique, implying that it
   would take at least 7 keys to find a 64-bit collision
   (test suggested by ceebo)

2. All pairs of XORed keys are unique modulo 2^32

3. The cardinality of { (key1 ^ key2) >> 48 } is as close
   as possible to the maximum (65536)

Point 2 aims at ensuring a good distribution among the bits
that determine an TT entry's cluster, likewise point 3
among the bits that form the TT entry's key16 inside a
cluster.

Details:

     Bitset   card(key1^key2)
     ------   ---------------
RKISS
     key16     64894   = 99.020% of theoretical maximum
     low18    180117   = 99.293%
     low32    305362   = 99.997%

Xorshift64*, old seed
     key16     64918   = 99.057%
     low18    179994   = 99.225%
     low32    305350   = 99.993%

Xorshift64*, new seed
     key16     65027   = 99.223%
     low18    181118   = 99.845%
     low32    305371   = 100.000%

Bench: 9324905

Resolves #148