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.