Assorted clean up in endgames

No functional change.
Union of 2 changes that failed with good score

This is a union of 2 changes:

A tweak of recaptures limit from Joona Kiiski
http://tests.stockfishchess.org/tests/view/52166d7c0ebc59319a242400

and a tweak of move count pruning from Leonid Pechenik
http://tests.stockfishchess.org/tests/view/5217c7e60ebc59319a242456

The set passed both short TC at 30+0.05
LLR: 2.96 (-2.94,2.94)
Total: 18936 W: 3723 L: 3566 D: 11647

And the usual long TC at 60+0.05
LLR: 2.95 (-2.94,2.94)
Total: 48962 W: 8837 L: 8487 D: 31638

bench: 3453945
Improve ARM compatibility

STANDALONE-TOOLCHAIN.html in Android NDK says:

It is recommended to use the -mthumb compiler flag to force the generation
of 16-bit Thumb-1 instructions (the default being 32-bit ARM ones).

If you want to target the 'armeabi-v7a' ABI, you will need ensure that the
following two flags are being used:

  CFLAGS='-march=armv7-a -mfloat-abi=softfp'

Note: The first flag enables Thumb-2 instructions, and the second one
      enables H/W FPU instructions while ensuring that floating-point
      parameters are passed in core registers, which is critical for
      ABI compatibility. Do *not* use these flags separately!

Thanks to Peter Osterlund for pointout this doc and for showing me
an example Makefile to follow.

No functional change.
Don't use lpthread for Android

Thanks to Peter Osterlund for the feedback.

No functional change.
Rewrite KBBKN endgame

This was thought to be a draw but the bishops generally win. However,
it takes up to 66 moves. The position in the diagram was thought to be
a draw for over one hundred years, but tablebases show that White wins
in 45 moves. All of the long wins go through this type of semi-fortress
position. It takes several moves to force Black out of the temporary
fortress in the corner; then precise play with the bishops prevents Black
from forming the temporary fortress in another corner (Nunn 1995:265ff).

Before computer analysis, Speelman listed this position as unresolved,
but "probably a draw" (Speelman 1981:109).

bench: 3453945
Fix check for bishop pair in material imbalance

Prefer pos.bishop_pair() to pos.count<BISHOP>(WHITE) > 1
because the first checks that the two bishops are on
different color squares.

Although the change seems to kick in only in very rare cases,
quite surprisingly it was able to pass SPRT test at short TC.

LLR: 2.95 (-2.94,2.94)
Total: 39818 W: 8174 L: 7956 D: 23688

bench: 3453941
Rewrite backward pawn detection

Use the new backmost_sq() instead of a loop.

No functional change.
Revert "Fix check for bishop pair in material imbalance"

Idea is sound but implementation is partial. Ryan and Joona noticed that
    we leave an hole in material table. Also we got another report by an user
    of an odd behaviour. Namely, if you start stockfish and from the prompt
    give 'bench' you get 3453941, then if you run again bench you get 3453940.

    The reason is that two different positions with the same number of pieces,
    but one with a bishop pair and another without have the same material key.
    But after Eelco patch also different material imbalance and this yields
    to this issue.

    Restesting at long TC shows the patch does not really contribute at
    ELO improvement. Actually patch failed at long TC.

    LLR: -2.97 (-2.94,2.94)
    Total: 23109 W: 4104 L: 4092 D: 14913

    So revert.

    bench: 3453945
Do not prune useless checks in QS

Passed both SPRT tests in "simplification mode", so with
elo0: -3.00 alpha: 0.05 elo1: 3.00 beta: 0.05

Short TC:
LLR: 2.96 (-2.94,2.94)
Total: 6243 W: 1302 L: 1195 D: 3746

Long TC
LLR: 2.96 (-2.94,2.94)
Total: 22972 W: 4124 L: 4020 D: 14828

bench: 4633330
Union of 2 changes

Union of

- LMR >= 3 plies from Gary tests.stockfishchess.org/tests/view/522522960ebc595d328fcafd

- allows() tweak from Reuven tests.stockfishchess.org/tests/view/5225fa1c0ebc595d328fcb53

Both passed Step I and failed Step II.

Instead this union passed both short TC:
LLR: 2.95 (-2.94,2.94)
Total: 14525 W: 3063 L: 2874 D: 8588

And long TC
LLR: 2.94 (-2.94,2.94)
Total: 31075 W: 5566 L: 5308 D: 20201

bench: 4238160
Singular extension at 8 plies also for PV nodes

Passed both short TC:
LLR: 2.96 (-2.94,2.94)
Total: 11451 W: 2455 L: 2282 D: 6714

And long TC
LLR: 2.96 (-2.94,2.94)
Total: 15813 W: 2907 L: 2723 D: 10183

bench: 3864419
Fix warning: double to float truncation

MSVC 2013 says:
warning C4305: '*=' : truncation from 'double' to 'float'

No functional change.
Remove unreachable values in mobility table

The possible maximum mobility cardinality (plus one in case of
zero squares available) is:

- Knights: max. 8  squares -> max. 9  entries
- Bishops: max. 13 squares -> max. 14 entries
- Rooks:   max. 14 squares -> max. 15 entries
- Queen:   max. 27 squares -> max. 28 entries

So remove the extra entries in the table.

Spotted by Dariusz Orzechowski.

No functional change.
Move draw by material check

It is more natural to test this case among
others material distributions.

No functional change.
Fix some comments in position.cpp

No functional change.
Change condition to use relative rank

No functional change
More readable space mask

No functional change.
Fix random moves when time < 10ms

In case we have less then 10ms to think as soon as
we wake up the timer, it immediately fires and calls
check_time() where due to condition:

elapsed > TimeMgr.maximum_time() - 2 * TimerResolution

the stop flag is set and search returns immediately, without
actually search anything.

Here the somewhat hacky fix is to start the timer after
at least one iteration as been completed.

No functional change.
Simplify unstoppable pawns evaluation

No functional change
Extend checks more in losing positions

Passed both short TC:
LLR: 2.98 (-2.94,2.94) [-1.50,4.50]
Total: 3974 W: 860 L: 741 D: 2373

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 16807 W: 2917 L: 2733 D: 11157

bench: 3767999