StandardAgent Collection algo detached iterator

[jgraley]

Following on from #165. As seen in 8110b6cfe8648c4420237a6d3376c4b25bbea724 under CHECK_ITERATOR_IN_CONTAINER in StandardAgent::DecidedQueryCollection() the iterator xit does not reference anything in xremaining and I will call that detached (it probably references something in x_decision or old_decision).

This could be remedied by:

1. Put xremaining under shared_ptr and swap around the copies until we're copying just before the erase (i.e. copy-on-write behaviour, where erase() is the write)
2. Make that copy a kind of Clone() operation, and give it the ability to carry iterators forward, i.e. reattach to the copy
3. This would need to be implemented differently for each underlying container type:
   • list: end()-1 after push_back(value)
   • set: find(value) after insert(value) due uniqueness
   • multiset: some combination of the above?

However, I don't want to do any of that. Wider concerns seem to suggest it's time to do Collection decisions differently:

• Decisions (DecidedQuery::Range) are to include a set of exclusions. When conjecture increments, it will increment past these. No, do it in a new SubCollectionRange which uses new iterators that do the jumping - this is needed to avoid touching the replace code
• Exclusions are to be iterators on the supplied container, not values, to avoid regressing #165 Still good
• StandardAgent::DecidedQueryCollection() to fill these in as non-star patterns are matched off. And the NLQ!
• Thus, DQC() and NLQC() can register the original X node's Collection, similar to DQS()...
• ...and the shared_ptr in DecidedQuery::Range is not needed and may be removed. To collection? if so yes

Note that while it feels bad to put this set into decisions, the size of the set depends only on pattern: it's always <= the number of non-star children in the collection in the pattern. Also, this strategy is the one that will eventually be used by the CSP for collection multiplicities.

[jgraley]

Regarding the new SubCollectionRange class:

• [x] Move all the existing functionality in SubSequenceRange to its base SubContainerRange. This is not strange because all that stuff is orderedness-agnostic as it turns out.
• [x] Fiddle around with OOStd stuff until ContainerInterface::iterator (the one that holds refs to the real iterators so it can be concrete and yet generic) implements iterator_interface.
• [x] Implement a SubContainerRangeWithExclusions that uses a new iterator derived from ContainerInterface::iterator but which holds a set of exclude iterators (via shared_ptr) and skips them. Hopefully only need to replace constructor and modifiers.
• [x] SubCollectionRange trivially derives from SubContainerRangeWithExclusions. Exclusion set is a set of iterators.
• [x] Usage in DQ, NLQ: begin, end and exclusions should all be iterators on the collection in the x tree. begin and end should be the collection's begin and end. Exclusions can all be obtained from nuggets of knowledge corresponding to the non-star x links.

SubContainerRangeWithExclusions could support other values for begin/end for example to avoid the need for exclusions for things at back or front - but I don't propose to use this. We do need (at least one of) them if we're going to drop the container pointer from Range, though.

[jgraley]

SubCollection should now fall out of use: delete it - see #231 Keeping around for replace, but removed elts for #231