Additional renaming from DON

Assorted renaming and triviality.

No functional change.
Fix magic boosters conversion

Fix small overflow error while converting
magic boosters from right rotate to left rotate,
in particular booster 38 was converted to 4122
instead of the corrcet value 26.

Formula used was:

s1 = original & 63, s2 = (original >> 6) & 63;
new = (64 - s1) | ((64 - s2) << 6);

Instead of:

s1 = original & 63, s2 = (original >> 6) & 63;
new = ((64 - s1) & 63) | (((64 - s2) & 63) << 6);

This has no impact in number of cycles needed, but
just in the resultig number that yields to a rotate
amount bigger than 63.

Spotted by Ehsan Rashid.

No functional change.
Return static eval when reaching MAX_PLY

Makes more sense than returning a draw score. Tested
with reduced MAX_PLY = 30 and passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 17434 W: 3345 L: 3194 D: 10895

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 2610 W: 488 L: 373 D: 1749

With current limit of MAX_PLY = 100 the patch should not
introduce any measurable change, nevertheless is the correct
approach.

Idea of returning eval is from  Michel Van den Bergh.

bench: 8430785
Assorted renaming in search

Inspired by DON.

No functional change.
Rename ProbCut to Multicut

The teqnique used is actually MultiCut:

https://chessprogramming.wikispaces.com/Multi-Cut

And not ProbCut:

https://chessprogramming.wikispaces.com/ProbCut

No functional change.
Reformat of eval tracing code

Also assorted rename while there.

No functional change.
Restore PorbCut name

Actually MultiCut is too different from current scheme.
Note that neither ProbCut is exactly what we do because
we try just a handful of captures instead of all moves,
nevertheless it seems more in line with what we do.

Suggested by Joona.

No functional change.
Fix material key for King

Currently king has no material key associated because
it can never happen to find a legal position without
both kings, so there is no need to keep track of it.

The consequence is that a position with only the two
kings has material key set at zero and if the material
hash table is empty any entry will match and this is
wrong.

Normally bug is hidden becuase the checking for a draw
with pos.is_draw() is done earlier than evaluate() call,
so that we never check in gameplay the material key of a
position with two kings.

Nevertheless the bug is there and can be reproduced setting
at startup a position with only two kings and typing
'eval' from prompt.

The fix is very simple: add a random key also for the king.

Also fixed the condition in material.cpp to avoid asserting
when a 'just 2 kings' postion is evaluated.

No functional change.
Increase MAX_PLY from 100 to 120

Under some very rare case 100 plies of search
could be not enough. Increasing more could lead
to crashes due to reached stack size limit on
some platforms.

Strongly requested by Uri.

bench: 8430785
Sync code style in material.cpp

Update to use common code style.

No functional change.
Update SEE to return a Value

It seems more natural because the actual returned
value is from PieceValue[] array.

No functional change.