This will allow an iterator to handle aborted versions and undone
object creations.  XXX Still need a test for the latter.

XXX checkTransactionalUndoIterator() should too, but doesn't.

# XXX need a test case that covers iteration over a storage that
# includes a transactional undo that un-created an object.

If supplied, they are stored as metadata on the transaction object.
This is helpful for debugging.

It's not thread-safe to store a Transaction() object in an instance
variable without some sort of locking.  Nor is it desirable to use the
same transaction object for more than one transaction.

So get rid of all uses of self._transaction and replace with a local
variable.

running the rest of the tests in the child.

Let super tearDown() close the storage.

Tracking changes to ZODB/tests/StorageTestBase.

running the rest of the tests in the child.

The Standby-branch was branched from the StandaloneZODB-1_0-branch,
which includes the BTrees-fsIndex code.  I didn't include that change
in the merge, but everything else.  Terse summary follows:

BTreeModuleTemplate.c:
    Greg Ward's ConflictError patch

The Standby-branch was branched from the StandaloneZODB-1_0-branch,
which includes the BTrees-fsIndex code.  I didn't include that change
in the merge, but everything else.  Terse summary follows:

BaseStorage.py:
    Add read-only storage feature.
    Add TransactionRecord and DataRecord marker classes for iteration.
    Reformat some lines.

FileStorage.py:
    Add read-only storage feature.
    Greg Ward's ConflictError patch
    Reformat some lines.
    Add lastTransaction(), lastSerialno().
    Add bounds support to iterator().
    Use TransactionRecord and DataRecord.

Connection.py:
DemoStorage.py:
MappingStorage.py:
    Greg Ward's ConflictError patch

POSException.py:
    Greg Ward's ConflictError patch
    Add ReadOnlyError.

as argument

- replaced assert statements by calls to self.assertEqual() and
  self.assert_()

calculated index fuer ..SetItem()

Add __getstate__() and __setstate__() methods.

Thanks to Chris McDonough for helping me see the problem.

There are extensive comments that discuss the backwards compatibility
issues.  Basically, we must be careful that the pickles these methods
operate on are just like the pickles generated by the old code, or
developers couldn't switch back and forth between new and old code.
That's a incompatibility we aren't willing to live with for now --
perhaps not ever.

    # If the internal representation of PersistentMapping changes,
    # it causes compatibility problems for pickles generated by
    # different versions of the code.  Compatibility works in both
    # directions, because an application may want to share a database
    # between applications using different versions of the code.

    # Effectively, the original rep is part of the "API."  To provide
    # full compatibility, the getstate and setstate must read and
    # right objects using the old rep.

    # As a result, the PersistentMapping must save and restore the
    # actual internal dictionary using the name _container.

As the checkin message on the branch said, this should make the new
code work correctly using pickles generated by the old code.

The doc string for __changed__() says that it is deprecated, but
presumably the calls here were old and just never got updated.