Tweak bishop PSQT tables

Tuned after 49K iterations of SPSA.

Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 14231 W: 2684 L: 2542 D: 9005

And long TC:
LLR: 2.94 (-2.94,2.94) [0.00,4.00]
Total: 87556 W: 13757 L: 13342 D: 60457

bench: 6875743
H-file penalty and center bonus

After almost 50K at long TC it seems
slightly positive:

ELO: 1.73 +-1.8 (95%) LOS: 97.3%
Total: 47122 W: 7507 L: 7273 D: 32342

bench: 8430785
Better document razoring

Use ralpha instead of rbeta

* rbeta is confusing people. It took THREE attempts to code razoring
at PV nodes correctly in a recent test, because of the rbeta trick.
Unnecessary tricks should be avoided.

* The more correct and self-documenting way of doing this, is to say
that we use a zero window around alpha-margin, not beta-margin.
The fact that, because we only do it at PV nodes, alpha happens to be
beta-1 and that the current stuff with rbeta works, may be correct,
but is confusing.

Remove the misleading and partially erroneous comment about returning
v + margin:

* comments should explain what the code does, not what it could have done.

* this comment is partially wrong in saying that v+margin is "logical",
  and that it is "surprising" that is doesn't work.

From a theoretical perspective, at least 3 ways of doing this are equally
defendable:

1/ fail hard: return alpha: The most conservative. We bet that the search
will fail low, but we don't know by how much and don't want to take risks.

2/ aggressive fail soft: return v (what the current code does). This
corresponds to normal fail soft, with the added assumption that we don't
care about the reduction effect (see below point 3/)

3/ conservative fail soft: return v + margin. If the reduced search (qsearch)
gives us a score <= v, we bet that the non reduced search will give us a
score <= v + margin.

* Saying that 2/ is "logical" implies that 1/ and 3/ are not, which is
arguably wrong. Besides, experimental results tell us that 2/ beats 3/,
and that's not something we can argue against: experimental results are
the only trusted metric.

* Also, with the benefit of hindsight, I don't think the fact that 2/ is
better than 3/ is surprising at all. The point is that it is YOUR turn to
move, and you are assuming that by NOT playing (and letting the opponent
capture your hanging pieces in QS) you cannot generally GAIN razor_margin(depth).

No functional change.
Better document null search window

Hopefully this patch makes the code more:

* Self-documenting: Null search is always a zero window search,
  because it is testing for a fail high. It should never be done
  on a full window! The current code only works because we don't
  do it at PV nodes, and therefore (alpha, beta) = (beta-1, beta):
  that's the kind of "clever" trick we should avoid.

* Idiot-proof: If we want to enable null search at PV nodes, all we
  need to do now is comment out the !PvNode condition. It's that simple!

In theory, null search should not be done at PV nodes, because PV nodes
should never fail high. But in practice, they DO fail high, because of
aspiration windows, and search inconsistencies, for example. So it makes
sense to keep that flexibility in the code.

No functional change.
Retire null search verification

Tested with SPRT in simplification mode [-4.00,0.00],
this ensures that the patch is (very probably) not
a regression.

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 27543 W: 4278 L: 4209 D: 19056

And long TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 39483 W: 7325 L: 7305 D: 24853

bench: 8347121
Don't fear races when are harmless

Actually race conditions do exist in an engine, just
think for a moment to TT concurrent access. Racy code
is not a problem per se, if the consequences are well
known and correctly handled.

In case of TT access we ensure that the TT move is validated
before to be tried, here we just retry the same move in less
that 1 case out of a million: this is totally harmless considering
that very probably the second time the move is tried we get
immediately a TT hit and search quickly returns.

So we simplify the code for no harm.

No fuctional change (in single thread case)
Inline common path of pos.gives_check

Test for common case which, when running default
stockfish bench, avoids 96% of 19 million calls to
pos.gives_check().

Yields to a 2-4% speed up according to platform.

Passed fishtest at STC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 12441 W: 2333 L: 2196 D: 7912
http://tests.stockfishchess.org/tests/view/52f02d790ebc5901df50f887

Passed fishtest at LTC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 42175 W: 6702 L: 6409 D: 29064
http://tests.stockfishchess.org/tests/view/52f0dbe00ebc5901df50f8a0

No functional change.
Rewrite previous patch removing the macro

No functional change.