Fix setting _p_changed for small pure-Python BTrees.

[jamadden]

When working on zopefoundation/zc.zodbdgc#1, we found a bug in the pure-Python BTree implementation. An elif that should have been its own if prevented the second and subsequent additions to a BTree from setting the _p_changed flag, right up until the first bucket needed to split.

This can cause data-loss for small BTrees.

This PR adds a test case and should fix the issue (the comment is copied from the C implementation).

[tseaver]

This fix LGTM. I plan to experiment with the new test (verifying failure in py27-pure, success in py27) before merging. Too bad the darned test suite takes so long to run.

[jamadden]

It definitely fails for me without the change and works with it, but of course feel free to confirm, extra eyeballs are always a good thing :)

[master]$ pypy `which nosetests` BTrees.tests.test_OLBTree:OLBTreeTest.testAddTwoSetsChanged
F
======================================================================
FAIL: testAddTwoSetsChanged (BTrees.tests.test_OLBTree.OLBTreeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "BTrees/BTrees/tests/common.py", line 1121, in testAddTwoSetsChanged
    self.assertTrue(t._p_changed)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
[master]$ cd fixed
[fixed]$ pypy `which nosetests` BTrees.tests.test_OLBTree:OLBTreeTest.testAddTwoSetsChanged
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK

On my machine at least, the Python 2.6 tests run almost twice as fast as many of the other versions (90s vs 193s for Py2.7). Travis runs them all about the same...I wonder why that is...

[tseaver]

I forgot that the py27 tests would exercise the pure-Python stuff, too. I can definitely verify the fix.

[tseaver]

Thank you!