Added 'throws' clauses to Java method signatures for all wrapped
functions except getters.  refs #1011
Flag rename:
	WT_SYNC_DISCARD changes to WT_SYNC_CLOSE
	WT_SYNC_DISCARD_NOWRITE changes to WT_SYNC_DISCARD
Rename WT_EVICTION_LOCKED to WT_EVICTING, we're going to set it when
closing files as well as when evicting pages via the eviction server.
The meaning is when that flag is set and there's an update we can't
write, we quit reconciliation early because the page cannot be evicted.

Change the __evict_file() support for close to set the WT_EVICTING flag,
but not set the WT_SKIP_UPDATE_ERR flag.  This change means the EBUSY
we get when attempting to close a file that has updates that aren't yet
globally visible surfaces in the connection data handle code, rather
than resulting in a panic inside of reconciliation.

Move the reconciliation "panic if not allowed to skip updates" code back
into the code that first encounters those updates, rather than checking
at reconciliation wrapup -- it shouldn't be a change to the semantics,
but I think it's a little safer/cleaner/consistent.
Reconciliation, when closing a file, can now see child pages in a
WT_REF_MEM state, they're empty pages we're about to merge into the
page we're reconciling.  We haven't seen this state before because the
eviction server would have set these pages to WT_REF_LOCKED during its
review of the selected page's subtree.

Relax the constraint (the only alternative I can think of would be to
switch to doing "real" eviction, where we switch the page's state to
WT_REF_LOCKED, and that has its own problems, this is a lot simpler).
typo
typo
Merge branch 'develop' into separate-close-thread
Merge branch 'develop' into separate-close-thread
First attempt to add a sweep thread to close data handles only after
they've been quiescent for awhile.

Change "normal" close to decrement the data handle's use count, and
nothing more.

Remove the old sweep code (which happened when objects were opened,
based on the dead-handle count we no longer maintain).
Change the data handle decrement to an atomic operation, removing the
need for the schema lock when closing a data handle, push that change
up into the tree; specifically, we no longer need to acquire the schema
lock when closing a session.
Merge pull request #1018 from wiredtiger/separate-close-thread

Close files in a separate thread.
Fix handle sweep code: make sure we're closing the right data handle, check the reference count before freeing, and use atomic increment to match the (unlocked) atomic decrement on close.

refs #844
Don't worry about handles that are referenced during connection close.

refds #844
Merge pull request #1015 from wiredtiger/java-exception

Updated java exception clauses
Test some more basic access method types and other variants in format
and thread check runs.
Fix up a couple of comments.
Change WT_STRING_MATCH to cast its argument before doing pointer
arithmetic on it.
Merge branch 'develop' into json-dump