The current state of this code is messy. It's not clear why we use
MAX_PLY = 120, or why we use MAX_PLY+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:
  - stop condition is now ss->ply >= MAX_PLY and not ss->ply > MAX_PLY.
  - assert(ss->ply < MAX_PLY), before using ss+1 and ss+2.
  - as a result, we don't need the artificial MAX_PLY+6 range. Instead we
  can use MAX_PLY+4 and it's clear why (for ss-2 and ss+2).

* 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, and now 0..MAX_PLY-1).

Tested with debug compile, using MAX_PLY=16, and running bench at depth 17,
using 1 and 7 threads. No assert() fired.

No functional change.