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.