Cleanup MAX_PLY

The current state of this code is a mess. It's not clear why we use
MAX_PLY = 120, or why we use MAX_PLY_PLUS_6, among other things...

This patch does the following:

* ID loop: depth ranges from 1 to MAX_PLY-1, and due to TT constraint (depth
must fit into an int8_t), MAX_PLY should be 128.

* stack[]: plies now range from 0 to MAX_PLY-1, hence stack[MAX_PLY+4],
because of the extra 2+2 padding elements (for ss-2 and ss+2). Document this
better, while we're at it.

* Enforce 0 <= ply < MAX_PLY everywhere:
  - stop condition shall be ss->ply >= MAX_PLY and not ss->ply > MAX_PLY.
  - test ss->ply >= MAX_PLY, BEFORE using ss+1 and ss+2, and assert
  0 <= ply < MAX_PLY in search() and qsearch().
  - as a result, we don't need the artificial MAX_PLY+6 range.

* ss->ply computed directly before searching, avoinding an extra calculation
on the critical execution patch of search() and qsearch().

* fix: extract_pv_from_tt() and insert_pv_in_tt() had no reason to use
MAX_PLY_PLUS_6, because the array is indexed by plies, so the range of
available plies applies (0..MAX_PLY before the patch, now 0..MAX_PLY-1).

No functional change.
What about stacks copied after a split point? Or you add the same loop copying also when splitting or (as I'd prefer) you just leave ss->ply to be set at runtime as it is now.