Clean up the fast-delete code (part of doing a review after merging the
new-split branch into develop).

Specific changes:

The code to rollback a fast-delete change has to loop, it's possible for
the instantiation to fail, returning the page to "deleted" status.  Add
a comment clarifying why we can't read a copy of the page (we don't
always have an open cursor on the tree when rolling back a transaction).

Add a new function __wt_page_parent_modify_set that dirties a parent
page.  It's only used in a couple of places, but it has a comment
explaining why dirtying a parent page is safe even in the face of
on-going splits that might be deepening the tree.

Note, these changes aren't sufficient for fast-deletes in the new-split
branch: while it's safe to update the single, instantiated page in-place
once it's set to an in-memory state (there is obviously an unresolved
transaction, the page isn't going anywhere), the problem is if the page
were to split.  In that case, the changes could be spread across
multiple physical pages, and the transaction unroll won't find them all.
Make lint happier, list the WT_REF states we're ignoring.
WT_REF_SPLIT is possible, I believe, and it's a problem.
typo, introduce an infinite loop into the test suite.
Fix the problem where a truncated/deleted page might split (meaning
there's no single place the truncate abort can go to find the list
of WT_UPDATE structures).  The primary change is to replace the
WT_REF.txnid field with the WT_REF.page_del field.  The new field
holds both the transaction ID, and, if necessary, an array of
WT_UPDATE structures so abort can find them even after the page splits.
Minor cleanup to simplify the tree-walk code, simplify function naming,
too.
Merge pull request #951 from wiredtiger/new-split-fast-delete-2

Fix the problem where a truncated/deleted page might split.
Merge pull request #948 from wiredtiger/new-split-fast-delete

Clean up the fast-delete code (review after merging the new-split branch).