The stat "clear" function isn't correct for initialization because it
ignores some fields, its intent is to clear specific fields between
stat calls, not clear the whole structure.  Add clear functionality
to the stat initialization function so it can be used to refresh stat
structures.

Change the name of the stat "clear" function to "refresh" so nobody
makes this mistake in the future (but don't drive that change out to the
application-level, "clear" is still the right way for the application
programmer to think about this).

Change the LSM and the table statistics aggregation code to always call
the statistics structure's init function, that will clear any previous
values.
Rework the statistics logging code to aggregate information from any
open handles, so, for example, the statistics from open checkpoint
handles will be logged.

Rework the statistics logging code to call __wt_curstat_open rather
than using application-level calls, that matches LSM's behavior and
I think it's cleaner and more correct.

This changes __wt_conn_btree_apply() to take a new argument flagging
it's supposed to return checkpoint handles as well as non-checkpoint
handles.

Ref #709.
Change table statistics to use standard statistics aggregation code
instead of rolling its own, otherwise we aggregate values like file
magic numbers and file versions.
Table statistics no longer needs WT_STAT_INCRKV, and no other code
uses it, remove it.
Copy one set of statistics from the first chunk, otherwise base statistics
like the file magic number and block version won't get set.
Make the allocation code for an aggregate statistics structure look the
same for table and LSM, don't initialize the LSM aggregate, the copy of
the first chunk's statistics does that for us.
cleanup, __wt_backup_list_all_append is a local function, remove leading __wt.
When locking the schema file, assert that it's not already locked, the
underlying locking primitives won't always detect self-deadlock.
A different approach to aggregating checkpoint handle statistics; when
retrieving the cursor statistics for a file URI, run through the list
of open handles and aggregate statistics for any checkpoint handles on
the same underlying URI.

This backs out most of the previous changes to conn/conn_stat.c on this
branch.

Some notable changes along the way:

Don't bother doing next/prev on the statistics cursor in the stat log
server code, we know where the values are, just get them.

When opening the statistics cursor in the stat log server code, use a
default cursor configuration.

This means btree cursors potentially require a copy into a separate
WT_DSRC_STATS structure (just like tables and LSM); bite that bullet and
do it all the time both for btree cursors and connection statistics
cursors.  That means we (1) don't need to pin the underlying btree but
can immediately release it, and (2) don't have to remember how to clear
the underlying statistics when we close the statistics cursor, we can
clear them immediately after the copy.
Quit allocating the statistics cursor's stat structures separately from
the cursor itself, add a union of the possible statistics structure to
the cursor itself.

Fix bug found by inspection -- set WT_CURSOR_STAT.notpositioned for table,
colgroup and index statistics cursors.
Fix to clear the aggregated checkpoint handle statistics structures.
Check for WT_NOTFOUND as well as EBUSY/ENOENT, it's safer and costs
nothing.
Cleanup error handling; don't jump to an err: label in the middle of a
function.
Allocate the local variables at the start of the function, our style
is to not usually allocate at other than a function scope.
Fix compiler warning:

../src/conn/conn_stat.c: In function '__statlog_dump':
../src/conn/conn_stat.c:144: warning: implicit conversion shortens
64-bit value into a 32-bit value
Merge pull request #717 from wiredtiger/statistics-checkpoint

Update how we aggregate statistics on handles, so that it is done more consistently.

Include statistics from checkpoint handles in btree statistics.
style, u_int64_t -> uint64_t.
Minor code shuffling, create a single statistics-cursor-init wrapper
function, move lsm statistics-cursor-init function into lsm/lsm_stat.c,
it grabs the schema lock and that's worth knowing.
With spinlock logging, there will is potentially a lot more reports we skip,
number the reports sequentially instead of using an absolute number.
Review %d format usage, fix where it should have been something else.