Reimplement PySequence_Contains() and instance_contains(), so they work

safely together and don't duplicate logic (the common logic was factored
out into new private API function _PySequence_IterContains()).
Visible change:
    some_complex_number  in  some_instance
no longer blows up if some_instance has __getitem__ but neither
__contains__ nor __iter__.  test_iter changed to ensure that remains true.

Lib/test/test_iter.py

@@ -474,24 +474,12 @@ class TestCase(unittest.TestCase):
 
     # Test iterators with 'x in y' and 'x not in y'.
     def test_in_and_not_in(self):
-        sc5 = IteratingSequenceClass(5)
-        for i in range(5):
-            self.assert_(i in sc5)
-        # CAUTION:  This test fails on 3-12j if sc5 is SequenceClass(5)
-        # instead, with:
-        #     TypeError: cannot compare complex numbers using <, <=, >, >=
-        # The trail leads back to instance_contains() in classobject.c,
-        # under comment:
-        #     /* fall back to previous behavior */
-        # IteratingSequenceClass(5) avoids the same problem only because
-        # it lacks __getitem__:  instance_contains *tries* to do a wrong
-        # thing with it too, but aborts with an AttributeError the first
-        # time it calls instance_item(); PySequence_Contains() then catches
-        # that and clears it, and tries the iterator-based "contains"
-        # instead.  But this is hanging together by a thread.
-        for i in "abc", -1, 5, 42.42, (3, 4), [], {1: 1}, 3-12j, sc5:
-            self.assert_(i not in sc5)
-        del sc5
+        for sc5 in IteratingSequenceClass(5), SequenceClass(5):
+            for i in range(5):
+                self.assert_(i in sc5)
+            for i in "abc", -1, 5, 42.42, (3, 4), [], {1: 1}, 3-12j, sc5:
+                self.assert_(i not in sc5)
+            del sc5
 
         self.assertRaises(TypeError, lambda: 3 in 12)
         self.assertRaises(TypeError, lambda: 3 not in map)