Make operator<< to return void

This should help preventing misuse.

No functional change.
Queen vs. 3 pieces imbalance

Passed both STC
LLR: 7.32 (-2.94,2.94) [-1.50,4.50]
Total: 98108 W: 18087 L: 17576 D: 62445

And LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 15082 W: 2417 L: 2248 D: 10417

bench: 7717336
Update Readme to 128 max threads

No functional change.
Speed up apply_weight

Speed up by about 2% this hot path function pre-calculating
midgame and endgame values of the weight.

No functional change.
Remove QueenOn7th and QueenOnPawn

Small simplification.

Passed SPRT(-3,1) both at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17051 W: 3132 L: 3005 D: 10914

and LTC:
LLR: 4.55 (-2.94,2.94) [-3.00,1.00]
Total: 24890 W: 3842 L: 3646 D: 17402

The rationale behind this is that I've never managed to add a
Queen on 7th rank bonus in DiscoCheck, because it never showed
to be positive (evne slightly) in testing. The only thing that
worked is Rook on 7th rank.

In terms of SF code, it seemed natural to group it with QueenOnPawn
as well as those are done together. I know you're against groupping
in general, but when it comes to non regression test, you are being
more conservative by groupping. If the group passes SPRT(-3,1) it's
safer to commit, than test every component in SPRT(-3,1) and end up
with the risk of commiting several -1 elo regression instead of just
one -1 elo regression.

In chess terms, perhaps it's just easier to manouver a Queen (which
can more also diagonaly) than a Rook. Therefore you can let the search
do its job without needing eval ad-hoc terms to guide it. For the Rook
which takes more moves to manouver such eval terms can be (marginally)
useful.

bench: 7473314
Smaller and faster profile-build binaries

I have noticed that increasing the bench depth produces
progressively smaller and slightly faster executables at
the cost of longer compile times.  Also using bench "time"
instead of "depth" seems to produce slightly smaller/faster
executables  given comparable compile times.

I have made a new Makefile that generates smaller and
about 1% to 2% faster profile executables at only a
little extra compile time.  On  my mobile 2GHz i7 a
full profile build time goes from 3'48" to 4'13" and
the exe goes down by 5% from 416,310 bytes to 395,567
bytes.

No functional change.
Small tidy up in move_to_san

No functional change.
Some more work in pretty_pv

No functional change.
Sync some common names

No functional change.
Rescale UCI scores to PawnValueEg

This is more consistent with what other engines are doing.
Often people thinks that SF's scores are overblown. In the
end, it just boils down to the arbitrary way of rescaling them.

No functional change.
Restrict queen mobility to safe squares

Passed both STC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 16188 W: 3119 L: 2971 D: 10098

and LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 6336 W: 1010 L: 882 D: 4444

bench: 7533692
Add a penalty for low mobility pieces

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 81857 W: 14652 L: 14342 D: 52863

and LTC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 45400 W: 6999 L: 6697 D: 31704

bench: 7716978
Get rid of an evaluate_pieces() overload

Rewrite and greatly simplify that part of code.

No functional change.
Further simplification in evaluate

No functional change
Reduce penalty for doubled pawns further away from each other

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 38339 W: 6849 L: 6649 D: 24841

and LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 22693 W: 3455 L: 3256 D: 15982

bench: 7508468
Move LowMobPenalty into psq/mobility tables

Tested in no-regression mode.

Passed both STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 36705 W: 6537 L: 6443 D: 23725

and LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9358 W: 1495 L: 1358 D: 6505

bench: 6921356
Big reshuffle in evaluate.cpp

Reshuffle functions to define them in reverse
calling order (C style).

This allow us to define templates before they are
used. Currently it is not like this, for instance
evaluate_pieces is defined after do_evaluate that
calls it. This happens to work for some strange
reason (two phase lookup?) but we want to avoid
code that works 'by magic'.

As a nice side-effect we can now remove the function
prototypes.

No functional change.
Add PEXT software implementation

For development/debug purposes.

No functional change.
Implement PEXT based attacks

According to:

https://chessprogramming.wikispaces.com/BMI2#PEXTBitboards

No functional change.
Switch to hardware PEXT

Retire software pext and introduce hardware
call when USE_PEXT is defined during compilation.

This is a full complete implementation of sliding
attacks using PEXT.

No functional change.