Speed up picking of killers

Changing the order of the conditions gives
about 1% speed up!

No functional change.
Fix issues detected by Coverity Scan

Most of Coverity Scan reports are false
positives, but in rare cases we have
confirmed (very small) issues.

No functional change.
Speed up by almost 3%

This apparentely silly tweak allows
to speed up the bench by almost 3%.

Not clear why, repeating with perft,
the speed up vanishes.

Suggested by Jonathan Calovski.

No functional change.
Move game phase constants to enum Value

No functional change.
Reformatting in material.h

No functional change.
Remove rook passers eval completely

Tested in no-regression mode.

Passed STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17727 W: 3248 L: 3122 D: 11357

And (a very long!) LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 106327 W: 16258 L: 16265 D: 73804

bench: 7396783
We can add an integer to a Value

We have defined corresponding operators,
so rely on them to streamline the code
and increase readibility.

No functional change.
Remove some useless casts

No functional change.
Fix Intel compiler warnings

Fallout from previous patch: Intel compiler
is very noisy.

No functional change.
Don't need floor() in timeman.cpp

For positive numbers result is equivalent:
http://stackoverflow.com/questions/3300290/cast-to-int-vs-floor

Spotted by Joseph Ellis.

No functional change.
Remove other useless floor()

No functional change.
Minor stuff scattered around

Just random minor stuff I found while browsing the code.

No functional change.
Rearrange interpolation formula

Put the division at the end to reduce
rounding errors. This alters the bench
due to different rounding errors, but
should not alter ELO in any way.

bench: 7615217
Penalize hanging pieces

Passed both STC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 8519 W: 1565 L: 1440 D: 5514

And LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 60618 W: 9141 L: 8777 D: 42700

bench: 8678654
Fix a compile error with Intel C++

Intel compiler is very picky:
"error: this operation on an enumerated type requires an
applicable user-defined operator function"

Reported by Tony Gaor.

No functional change.
Remove dead code in search

We can never have bestValue == -VALUE_INFINITE at
the end of move loop because if no legal move exists
we detect it with previous condition on !moveCount,
if a legal move exists we never prune it due to
futility pruning condition:

bestValue > VALUE_MATED_IN_MAX_PLY

So this code never executes, as I have also verified
directly.

Issue reported by Joona.

No functional change.