Support expressions in selectattr/rejectattr again, more efficiently

[tectonic8]

Redoes the changes made (and reverted) in #238 to support full expressions as the first argument to the selectattr filter. The previous approach caused performance issues because of the generation of a unique expression for each value processed in the sequence. These expressions all get saved in the context (code), making iterating through resolved expressions and even just checking membership in the set (code) unwieldy.

This PR uses the same expression string for processing each value and removes it from the context after we've finished iterating through the loop. Doing so not only avoids the bloated context issue, but also allows us to take advantage of caching in the TreeStore when parsing the expression string into a TreeValueExpression.

Locally testing this implementation on very large lists (of 10,000 elements) showed that performance is the same, if not slightly faster, than the current master branch implementation that only supports chained attributes, and an order of magnitude faster than the #238 implementation with unique expressions.

[mattcoley]

Nice work 👍 Let's make sure to test this in QA quite a bit after this is merged in.