Another run at handling removed overflow objects.  Michael suggested we could
append a copy of the removed overflow value to the WT_UPDATE list we're going
to save/restore as part of the eviction.  It's definitely a simpler approach
and keeps all the magic inside of reconciliation.

Add code to __rec_txn_read() to append a WT_UPDATE entry with a copy of the
original overflow value and a transaction ID of WT_TXN_NONE to the update
list being saved.   Rework __rec_txn_read() to obviously quit sooner and
avoid all the extra work, not sure if the compiler needs the hints, but it
can't hurt.

Remove the WT_PAGE_OVERFLOW_RM page flag.
Remove the code to detect removed-overflow objects when instantiating a
disk image.
Remove __wt_multi_inmem_ovfl_rm() entirely, plus the pass over the disk
image to clean up removed overflow objects as part of the eviction split.
Make it possible to force small keys so we never create overflow keys.
Make the new removed overflow approach work for row-store as well,
do some cleanup to simplify the code paths.

This version writes out entirely new overflow keys in the case of
removed overflow keys, which isn't optimal, but it's not incorrect.
Generalize overflow keys to look like overflow values, that is, set the
on-page cell to be WT_CELL_OVFL_REMOVE, and check that value instead of
searching the overflow cache for every key, every time.  This isn't in
the service of the new split code, but should speed up workloads with
overflow keys quite a bit.

Rename the cell flag WT_CELL_VALUE_OVFL_RM to WT_CELL_OVFL_REMOVE, it
now applies to both keys and values.

Move the caching of the removed overflow value to __wt_ovfl_cache(),
that way we don't nuke the on-page cell until after we successfully
cache the value.

Turn off "cleanup" in the on-page overflow cache, we can't back out the
changes to the cell.  (This is all going to go away soon, though, now
that we're flagging the on-page cells, we don't really need to track
removed overflow items past a single reconciliation.)
Simplify the code to figure out to which update list we should append
removed overflow values, it's the list that was passed in.
If we have a globally visible update, we don't need the removed overflow
value from the cache, if we don't have a globally visible update, it's an
error if we don't find the removed overflow value in the cache.
Minor comment cleanup.
More minor comment cleanup while reviewing txn_read.
whitespace
If the user didn't specif key/value min/max explicitly, correct so that
key/value min <= key/value max.
Merge branch 'new-split-overflow' into new-split-overflow-update
More key/value minimum/maximum changes to relax requirements for
specifying both, if you only specify one in the config file, we
adjust the other one as necessary.
Assert we only reset a cell once, and that it's the type we expect when
we reset it.

Verify the disk image we create in reconciliation for eviction splits.
If there's no value cell on the page, don't pass a previously unpacked
value cell to __rec_txn_read().
Simplify callers of __rec_txn_read() the WT_UPDATE list we're looking
at can be derived from the WT_INSERT/WT_ROW arguments.
We can't collapse removed key and value overflow items into a single
cell type: the code to find a row-store leaf page key's value has to
be able to distinguish between them because row-store leaf pages don't
store values that don't exist, so two adjacent keys (even removed
overflow keys), imply an empty value.
Change the overflow key/value addresses from a skiplist into a simple
linked list that's discarded after every reconciliation, we no longer
search it for any reason.
comment typo
If the on-page overflow cell is known to be WT_CELL_VALUE_OVFL_RM,
there's no reason to acquire/release the overflow lock, it's not
like the value gets re-instantiated somehow.  Fast path that case;
it's hard to imagine a workload where it makes a difference, but
it's not like it costs us much code, either.
When I switched __wt_cell_leaf_value_parse() to using the raw cell type,
I missed a couple of KEY types.