Replace the handling of a row-store page's newly allocated update structure
in __wt_update_serial_func() with an atomic swap into place in the caller.
Replace the handling of row- and column-store page newly allocated
page->u.row.ins, page->modify->update and page->modify->append
structures in their respective serial functions, with an atomic swap
into place in the caller.
Avoid some lint complaints.
Merge branch 'develop' into modify-update-atomic
Operator '-' followed by operator '-' is confusing.  Use parentheses.
Replace the handling of an allocated WT_INSERT_HEAD structure in the
serialization functions, with an atomic swap into place in the caller.
Ref #630.
Move the return of the allocated record number into the serialization function,
it's simpler than playing games with the WT_INSERT structure reference and it's
not going to be measurably slower.
If appending a record to an empty insert list, the ins_stack may
be filled with NULL values.
Fix a bug in test/format that prevented us from ever extending the
table by more than a single row.

Increase the distance we will potentially extend the table.
We just attempted to free a skip list where the head of the skip list had
a NULL field in the zero slot, but not in some of the other slots:

	(gdb) p append
	$2 = (WT_INSERT_HEAD *) 0x80504e0c0
	(gdb) p *append
	$3 = {head = {0x0, 0x805029080, 0x803d72040, 0x803d72040, 0x80501d3c0,
	0x804c2aa10, 0x804c2aa10, 0x804c2aa10, 0x0, 0x0}, tail = {0x805733460,
	0x805733320, 0x806ffb340, 0x80542be50, 0x80481e680, 0x80481eec0,
	0x803c2a5b0, 0x804c2aa10, 0x0, 0x0}}

I'm pretty suspicious this means there's still a bug in column-store appends,
but I'm going to fix this one, regardless.
No real change: just make the "inshead" naming match the rest of the
CURSOR_BTREE field naming, "ins_head" instead of "inshead".
Don't bother searching if the caller is appending a new record where
we'll allocate the record number; we're not going to find a match by
definition, and we're going to repeat the search when we do the work.
It's now possible to find a valid WT_INSERT_HEAD structure that's empty
when cursoring forward through the file.
Break apart a complex statement, make lint happy.
Move the test for an "empty" WT_INSERT_HEAD into the serialization function,
it's the only place where we know the list is empty and we have an element to
insert.
Don't extend the file if we still might return RESTART.  This isn't a real
bug, because the only place from which we might return RESTART is if we
find the record already inserted, and we know that's impossible in this
case, but it's a trivial restructuring of the code that might avoid future
bugs.
When I moved the set of the cursor's record number into the seralization
function, I set it only if the recno was append-flag allocated, which is
not right, we still need to set it if it's past the end of the object and
the caller set the recno explicitly.
The cursor's write-generation value is no longer used, it's only set and
then never read.  Remove it, along with the __wt_page_write_gen_check()
function.
Merge branch 'develop' into modify-update-atomic
Lint