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.

The implementation now defers all implementation decisions to UserDict
and merely handles updates to _p_changed in the PersistentMapping
implementation.  This change simplifies the implementation and ensures
that it implements all the new methods of dictionaries like popitem()
and setdefault().

There is one (important?) behavioral change:  The old implementation
of the keys() method did not return keys that were strings starting
with underscore.  This behavior was undocumented and could lead to
problems for implementations that expect keys() to working like a
regular mapping.

    The feature was removed after verifying that the Zope test suite
    does not depend on this behavior.

An internal implementation change is that the PersistentMapping does
not keep a copy of the keys() of the dict.  It simplifies the
implementation a lot to remove the cacheing and the benefit is
unclear.  It only benefits applications that call keys() frequently
without modifying the dict.  And it requires that two copies of the
list exist for each call to keys() which may require a lot of space.

Replaced it with a standard ValueError exception