Move the txn namespace into the KVS_SOURCE structure: there only needs
to be one txn per set of devices, not one per object, it's global to the
WiredTiger database.
Rename "log" to be "cache", it's not really a true log.
Missed a couple of uses of the per-object "txn" namespace, remove them.
Dual-license under either GPLv2 or GPLv3.
Write the code to marshall/unmarshall to/from the cache structure
(this version mostly works, supporting the cursor methods other than
search-near).

Add support for two new WT_EXTENSION API methods, collator_config and
collator; the former connects the current sessions collation cookie
to the WT_EXTENSION structure, the second calls it.  This is required
for the underlying data-source if it needs to order key/value pairs.
Merge branch 'develop' into memrata
On the first operation with a autocommit transaction, acquire the
transaction ID.   The layering is messed up here: normally we do
this check in the btree code immediately before we operate on a page
(because we want to acquire the ID at the last possible minute to
minimize conflicts).  For data sources, do it in the cursor, before
calling into the underlying data-source code.
More transactional code for the Memrata device.

Check if the update can proceed on inserts and updatest, fix the overwrite
stuff (again).  Probably still wrong, but I'll wait until I can run the
test suite to fix it.

Add support for setting the transaction state on commit/rollback; walk
the session handle and for every data-source cursor, call an underlying
commit or rollback function.  I don't see another solution, so I'm doing
this until Michael weighs in: I'm adding private WT_CURSOR methods the
data-source code sets, which is flatly wrong, but the other approaches
seem worse.

Another WT_EXTENSION_API method: the transaction_snapshot_isolation method
returns if snapshot isolation is configured for the current transaction.

Change the WT_EXTENSION_API transaction_id method to return the transaction
ID; it's no more likely to fail than the other transaction methods, and
I don't see them failing in the future either.   It's a little dangerous,
but I'd rather keep error handling simple if we can.