Retire KingExposed[] array

And merge its values into KPSQT table.

Passed blazingly fast both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 5348 W: 1091 L: 971 D: 3286

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 3029 W: 530 L: 415 D: 2084

bench: 8702197
Remove bishop pin bonus

Shows no regression at LTC after 20K games:

ELO: 0.03 +-2.7 (95%) LOS: 51.0%
Total: 20608 W: 3252 L: 3250 D: 14106

bench: 7516178
Rename pawn chain to connected

The flag raises also in case of a pawn duo, i.e.
when we have two adjacent pawns on the same rank,
and not only in case of a chain, i.e. when the two
pawns are on a diagonal line.

See this for a reference:
http://en.wikipedia.org/wiki/Connected_pawns

Renaming suggested by Ralph.

No functional change.
Simplify move_importance()

Drop a useless parameter. This works because ratio1 and ratio2
are ratios of linear combinations of thisMoveImportance and
otherMovesImportance and so the yscale cancels out.

Therefore the values of ratio1 and ratio2 are independent
of yscale and yscale can be retired.

The same applies to yshift, but here we want to ensure
move_importance() > 0, so directly hard-code this safety
guard in function definition.

Actually there are some small differences due to rounding errors
and usually are at most few millisecond, that's means below 1% of
returned time, apart from very short intervals in which a difference
of just 1 msec can raise to 2-3% of total available time.

No functional change.
Further simplify move_importance()

Function move_importance() is already always
positive, so we don't need to add a constant
term to ensure it.

Becuase move_importance() is used to calculate
ratios of a linear combination (as explained in
previous patch), result is not affected. I have
also verified it directly.

No functional change.
Simplify move_importance(): take 3

Use pow() of a negative number instead of 1/x

No functional change.
Update copyright year

No functional change.
Scale eval when down to only one pawn

Passed both short TC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 11921 W: 2346 L: 2208 D: 7367

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 21002 W: 3395 L: 3197 D: 14410

bench: 7602383
Ensure move_importance() is non-zero

In case ply is very high, function will round
to zero (although mathematically it is always
bigger than zero). On my system this happens at
movenumber 6661.

Although 6661 moves in a game is, of course,
probably impossible, for safety and to be locally
consistent makes sense to ensure returned value
is positive.

Non functional change.
Remove duplicated code

Introduce update_stats() and remove correspondng
duplicated code.

No functional change.
Fix a typo

Spotted by Isaac H. Dunn.

No functional change.
Merge remote-tracking branch 'upstream/master' into outposts