Split statistics macros into two parts: run-time and everything else,
that way if you open a statistics cursor on a file without configuring
run-time statistics, you can get information about the underlying table.
Merge branch 'develop' into statistics-split

Conflicts:
	src/btree/bt_io.c
	src/include/stat.h
	src/lsm/lsm_stat.c
	src/schema/schema_stat.c
Merge branch 'develop' into statistics-split
Merge branch 'develop' into statistics-split

Conflicts:
	dist/s_define.list
Merge branch 'develop' into statistics-split
API change: rework "run-time" and "tree-walk" statistics configuration.
Now, the database is configured for "none", "fast" or "all" statistics,
and each cursor is configured for "fast" or  "all" statistics, with the
additional flag "clear".  A cursor's statistics configuration must match
the database statistics cursor, defaulting to the current configuration.
The statistics_log configuration no longer defaults to "fast", it dumps
whatever the database is configured for.

Rename all of the macros from WT_RUNSTAT_XXX to WT_STAT_FAST_XXX.

Reference #715.
Fix the ex_stat example.
test clear/not-clear for both connection and data-source
Better testing of the "clear" configuration.
Better testing of the "fast" configuration, fix a bug, the btree code
wasn't looking at the cursor configuration when deciding whether or
not to return the expensive statistics.
style
Merge branch 'develop' into statistics-split
Merge branch 'develop' into statistics-split

Conflicts:
	src/btree/bt_ovfl.c
cfg->report_interval might be 0, just sleep a second at a time.
Fix the code for displaying the statistics, they weren't getting written.
Turn off statistics reporting in runner scripts.
Change the default statistics configuration from "fast" to "none".
If the default statistics setting is "none", we have to configure
statistics to test.
Add clear to the connection statistics configuration and remove "clear"
from the statistics_log configuration.

Add error checking, if you specify something like "statistics=(fast,all)",
it should fail.

Write some more statistics documentation.
If an error occurs early enough, conn->sessions won't have been
initialized.