Change "short" data items from 127B or less to be 63B or less, and use the
bit free'd up to mark short keys with a prefix-compression byte.   Ref #600.
When we aren't able to create a short key or value (and, in the case of a
value, there's no associated RLE), the key or value is at least 64B, else
we'd have been able to store it as a short cell.  Decrement/Increment the
size before storing it, in the hopes that relatively small key/value sizes
will pack into a single byte instead of two bytes.  Ref #600.
Add a comment to explain why we don't need to check the new value's
length, in the case of a short value cell, during dictionary lookup.
cell.i:483:6: error: conversion to 'unsigned int' from 'int' may change the sign of the result [-Werror=sign-conversion]
We previously instantiated a set of leaf page keys if Huffman encoding
was configured for keys; I think that's wrong.

Prefix-compression is the more interesting question: if a page has
prefix-compressed keys on it, we might want to pre-instantiate the
keys there, but Huffman encoding is just a CPU cost.
Minor cleanup of some logic.
The row-search function calls into underlying key functions that don't
expect to see garbage in the WT_ITEM structure.  Clear the structure,
but don't use memset, it's too expensive.
don't expect the search item to have any allocated memory (it's a  performance
problem if it does).  Trust, but verify, and complain if there's a problem.
"row search" is an internal term, simplify the complaint.
Clarify a comment, no other change.
We do data copies to the return WT_ITEM inside of __wt_row_leaf_key_copy()
where it's not necessary (for example, when returning keys and the key has
already been instantiated).  I don't believe this is actually a performance
problem at the moment, because __wt_row_leaf_key_copy() is front-ended by
__wt_row_leaf_key(), which is an inline function that checks for exactly
those cases and avoids the data copy.  (Well, with one exception, we would
do a lot more copies in the case of Huffman encoded keys, and a few more
copies if there was an unusual pattern of already instantiated
prefix-compressed keys on a page, but neither of those is likely to matter.)
Regardless, the data copies weren't necessary, and I'd rather make it clear
that __wt_row_leaf_key_copy() returns a reference, not a copy (and comment
the hell out of __wt_row_leaf_key()).

Don't bother inlining leaf-page key lookup in the salvage routines: it makes
no difference, and complicates thinking about __wt_row_leaf_key.
Merge pull request #602 from wiredtiger/row-leaf-key

Row-store leaf-page key retrieval.