Make evaluators symmetrical

[lrozenblyum]

Caused by #235 which showed an idea that for most correct comparison of evaluation results on different levels of the tree, we need comparable numbers.
It might mean that every evaluator should check not only OUR but the OPPONENT situation.
E.g. attack evaluator checks attackIndex(our) - attackIndex(opponent) and so on.

Split to #323
This may lead us to finally removing the concept of Position + Move evaluation and go to Position
evaluation.
Which may improve performance (due to reduced need of position.move generation)

At the moment some of our evaluators aren't symmetrical so that thinking for the 2'nd ply doesn't provide logical results because it analyzes different aspect of the position.
So as a matter of fact we compare uncomparable things.
For example castling safety for our side and castling safety for the opponent are totally different.

• We should make all evaluators analyze our and enemy position thus making them symmetrical

  • Think about generalizing 'index' calculation for us and the opponent
  • Castling safety is totally NOT symmetrical. Initially developed in Move decision - castling #131
    • Make it symmetrical
    • Ensure Normalized constraints are kept
    • Migrate to Normalized package
    • Should Position be enriched by getOccupiedSquares?
    • At the moment after king movement all moves are 0.5 which causes king movement itself evaluate fine but logically it's not fine as for me
    • Checks for ROOK and KING for the opponent look wrong
    • Fixed old bug: the evaluator encouraged moving one of rooks when there were piece in-between it and a king
    • Thinking for depth 2 reveals issue: comparing 'current' and 'next' situation is not fine when we think for 2'nd ply. Instead we should calculate some absolute value: fixed and extracted 2-ply evaluator for testability.
    • castling safety + 2'nd ply thinking doesn't want castling (since after castling king+rook is moved...)
  • Central control is totally NOT symmetrical. Initially developed in Move decision - center control #134
    • Make it symmetrical
    • Ensure Normalized constraints are kept
  • Mobility evaluator is NOT symmetrical. Initially developed in Move decision - mobility #132
    • Make it symmetrical
    • Ensure Normalized constraints are kept
    • relative vs absolute values: split to Mobility evaluator: relative mobility #322
  • Material evaluator IS symmetrical, and shows logical results
  • Protection evaluator is NOT symmetrical. Initially developed in Protectness #137
    • Make it symmetrical
    • Ensure Normalized constraints are kept
    • Protection evaluator should strategically protect its pieces even not attacked ones
    • (?) Maybe combine with Attack evaluator - cancelled. It's better to make them independent.
  • Attack evaluator is NOT symmetrical, may be to combine with Protection evaluator
    • Make it symmetrical
    • Ensure Normalized constraints are kept
    • (?) Maybe combine with Protection evaluator - cancelled. It's better to make them independent.
  • Special move evaluator is NOT symmetrical and looks obsolete. Just left comment. No intention to change it - split to Special move evaluator: decide what to do #330.

• Update evaluator factories: make denormalized call normalized - split to Update evaluator factories: make denormalized call normalized #328

• Our engine is smart enough to resign if it detects checkmate on the next move :)

• Core improvements

  • 2-ply evaluator extracted
  • 2-ply evaluation also returns values in normalized range
  • Range concept introduced and reused

• Evaluators independence is another interesting characteristic that is probably hard to achieve but it would be desired. to be investigated.

Final Expectation:

• Normalized brain with depth = 2 should prove that it's better than the brain with depth = 1 (see SimulatorIT)
• From human POV the analyzing should be more logical than in 0.4 - results to be improved in Material evaluator: increase importance #329
• Denormalized brain can be touched or untouched (to be defined). For simplicity we are allowed to do ANYTHING which doesn't break logical correctness.

[lrozenblyum]

Reported an issue fluxroot/jcpi#116 due to which our build fails