Cache dirty bytes

@agorrod, this is the best fix I can come up with for the cache dirty-bytes problem.

I think you're the best reviewer.

The commit explains what I did.

My primary concern is we could fall far enough behind (because we're not reconciling the page), that the cache would have a seriously incorrect count of dirty bytes.   Could that happen in a new tree, where we're just frantically inserting new data?

If that's a problem, I was thinking of doing something like this:

```
diff --git a/src/include/btree.i b/src/include/btree.i
index aa63fe0..45428fd 100644
--- a/src/include/btree.i
+++ b/src/include/btree.i
@@ -282,6 +282,8 @@ __wt_page_modify_init(WT_SESSION_IMPL *session, WT_PAGE *page)
 static inline void
 __wt_page_only_modify_set(WT_SESSION_IMPL *session, WT_PAGE *page)
 {
+	int64_t diff;
+
 	/*
 	 * We depend on atomic-add being a write barrier, that is, a barrier to
 	 * ensure all changes to the page are flushed before updating the page
@@ -300,6 +302,20 @@ __wt_page_only_modify_set(WT_SESSION_IMPL *session, WT_PAGE *page)
 		 */
 		if (F_ISSET(&session->txn, TXN_RUNNING))
 			page->modify->disk_snap_min = session->txn.snap_min;
+	} else {
+		/*
+		 * Make sure the cache's dirty-byte information for this page
+		 * isn't too far from reality -- if we're off by more than 10%,
+		 * fix it.
+		 */
+		diff = page->memory_footprint -
+		    page->modify->last_memory_footprint;
+		if (diff < 0)
+			diff = -diff;
+		if (diff > (int64_t)page->memory_footprint / 10) {
+			__wt_cache_dirty_decr(session, page);
+			__wt_cache_dirty_incr(session, page);
+		}
 	}
 }
```