Revert moveCountPruning alleged speedup

[FauziAkram]

Non-Functional simplification, reverting #4823 which probably was a fluke, as many other devs theorized over time.

As it was originally tested with only an stc test, for now I ran only an stc non-reg test.
However, if an LTC is required/preferred please let me know.

Passed stc:
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 88992 W: 22779 L: 22633 D: 43580
Ptnml(0-2): 137, 8706, 26681, 8818, 154
https://tests.stockfishchess.org/tests/view/6636c4844b68b70d85800dae

bench: 1480008

[mstembera]

But why? It clearly avoids unnecessary calls to futility_move_count() even if they are not significant enough to fail non regression bounds. It also makes it nice and obvious that once moveCountPruning is true it stays true. I could perhaps see writing
moveCountPruning = moveCountPruning || moveCount >= futility_move_count(improving, depth); to avoid the branch. Just my 2 cents.

[MinetaS]

I think the correct way to prove whether a speedup test is fluke or not, is to repeat the same test again with regular bounds, not with non regression bounds.

Not saying this is not a simplification, but as you mentioned the possibility of fluke, just giving my opinion about it.

[mstembera]

Just for tracking purposes https://tests.stockfishchess.org/tests/view/6649837bb8fa20e74c39f456 finished yellow +0.46elo after 700K games.