Accurate PV

This gives SF accurate PVs, such that the evaluation of the leaf node in the PV matches the score backed up to the root (99% of the time.  q-search will use the value stored in the hash table instead of the eval value sometimes).

One drawback is that fail-high/low only get a minimal 2 move PV.

It doesn't add any additional overhead to the non-PV codepath except an extra eight bytes to the SearchStack structure in multi-threaded searches.

A core part of this is not pruning based on TT score in PV nodes.  This was measured as not being a regression at multiple TCs, except for one exception, fast TC with huge hash, which is not realistic for longer searches.

STC - 1 thread, 128 mb hash
ELO: 1.42 +-3.1 (95%) LOS: 81.9%
Total: 20000 W: 4078 L: 3996 D: 11926

STC - 3 thread, 128 mb hash
ELO: -3.60 +-2.9 (95%) LOS: 0.8%
Total: 20000 W: 3575 L: 3782 D: 12643

STC - 3 thread, 8 mb hash
ELO: 0.12 +-2.9 (95%) LOS: 53.3%
Total: 20000 W: 3654 L: 3647 D: 12699

LTC - 3 thread, 32mb hash
ELO: 2.29 +-2.0 (95%) LOS: 98.8%
Total: 35740 W: 5618 L: 5382 D: 24740
I don't believe so.  In single threaded searches, no problem obviously :).  In multi-threaded searches, this is inside the splitPoint->mutex.lock().  If it's not a splitpoint, then the searchstack is per thread, so it's safe.