Don't reset the on-page cells to "overflow removed" until reconciliation
succeeds.  The problem is if we reset the on-page cells to "removed" and
then reconciliation fails, a future reconciliation would leak the
underlying blocks, it's assumed they're already gone.

Instead of tracking block addresses for discard after reconciliation,
track on-page cell pointers, then both free the blocks and reset the
on-page overflow cells to "removed" at the same time.

This change leaves overflow instantiation (key) and caching (values) to
the caller as before, that is, reconciliation must ensure the object is
instantiated or cached before reconciliation completes.

This change doesn't change the locking algorithm, but moves the locking
required when changing the on-page cell to a single place.

This change no longer holds a lock when caching the overflow value in
the page's reconciliation tracking structures, but that should be fine,
that memory is private to the page and the thread reconciling the page.
Merge pull request #922 from wiredtiger/new-split-overflow-update-lock

Don't leak blocks when reconciliation fails after resetting on-page overflow cells.