Bind 'in' operator more tightly than boolean operators.

[carljm]

When I added support for the 'in' operator a couple months ago, I think I got the precedence slightly wrong.

JS has no 'in' operator, so there's nothing to base nunjucks' behavior off there, but Python (https://docs.python.org/2/reference/expressions.html#operator-precedence) and Jinja both bind 'in' more tightly than boolean operators, so that this {% if msg.status in ['pending', 'confirmed'] and msg.body %} does not evaluate as {% if msg.status in (['pending', 'confirmed'] and msg.body) %} (which is what nunjucks master currently does).

I think the Python/Jinja behavior is more useful and logical than nunjucks' current behavior: in is a comparison operator, like == et al, and should bind with similar precedence. You wouldn't expect {% if msg.status == 'pending' and msg.body %} to evaluate as {% if msg.status == ('pending' and msg.body) %}.

This pull request fixes the precedence (and while I was at it, also adds a test to confirm that and binds more tightly than or, which is correct and matches both Python and JS).

[carljm]

I guess I can merge this myself, but wouldn't mind a review from somebody first.

[jlongster]

This looks great. Sorry I lapsed on looking at these PRs. Part of the problem was that I started following too many repos and was missing notifications, and I need to setup email filters from github to track them there.

[jlongster]

This is a breaking change, but not too bad, should be ok with a minor version bump (instead of just patch).