Fix Issue 114 -- And subiterators may move forward on Contains, even if the And ultimately doesn't

/cc @kortschak

It's a doozy. But I figured it out. And iterators need to return the passing subiterators to their previous result when one of the less-likely iterators fails. Turns out, it's not too bad to do this:

```
$ benchcmp before114.txt after114.txt 
benchmark                                   old ns/op       new ns/op       delta
BenchmarkNamePredicate                      979268          896046          -8.50%
BenchmarkLargeSetsNoIntersection            54808400        47252858        -13.79%
BenchmarkVeryLargeSetsSmallIntersection     552933674       594366653       +7.49%
BenchmarkHelplessContainsChecker            27324597023     24440393585     -10.56%
BenchmarkNetAndSpeed                        15850701        15109707        -4.67%
BenchmarkKeanuAndNet                        12942163        11829624        -8.60%
BenchmarkKeanuAndSpeed                      14878833        14207382        -4.51%
BenchmarkKeanuOther                         66035987        43568359        -34.02%
BenchmarkKeanuBullockOther                  77153687        73401643        -4.86%
```

This breaks the query with the huge result set (KeanuBullockOther) but breaks it by correctly responding. If you grep for '/film/film' in that set, you see the same (now fixed) pathology.