Feature Request: notcontains / does_not_contain Operator

Feature Request

Adding a notcontains operator to liquid would go a long way towards eliminating needless nested logic in liquid templates. As it stands, any time you need to check for the absence of a value, you have to invoke an unless statement with the contains operator. If this is combined with other logical conditions, it requires you to nest an unless statement inside of your if statement, rather than just using a single if statement with multiple conditions.

Example

Let’s say I have the following code I want to write:

{% if product.price > 10 and product.tags !contains "on_sale" %}
  ... do stuff ...
{% endif %}

To write this in a way that actually works, I need to do this:

{% if product.price > 10 %}
  {% unless product.tags contains "on_sale"
    ... do stuff ...
  {% endunless %}
{% endif %}

Or alternatively:

{% if product.tags contains "on_sale" %}
  {% assign is_on_sale = true %}
{% else %}
  {% assign is_on_sale = false %} <--- If I'm in a for loop, I need to prevent the value from carrying over from the last iteration 
{% endif %}
{% if product.price > 10 and is_on_sale != true %}
  ... do stuff ...
{% endif %}

Obviously it would be preferable if the first, very simple option was possible. To avoid using the arbitrary negation flag (!), the operator could be implemented as another keyword, e.g. notcontains or does_not_contain.

Background

There is another open issue from 2012 primarily regarding the implementation of a not operator, but as I see I see it, virtually everything you would need a not operator for can be accomplished by comparing with built in values like blank and empty. The only reason I've ever needed to use an unless statement has been to negate a contains operator. Implementing a not_contains filter would solve the problem without any of the complexity or compatibility concerns of an arbitrary negation operator.

Start by reviewing how Liquid currently parses and evaluates the contains operator, then read the related discussion in issue #138. Done requires a decided operator spelling and behavior, with coverage for absence checks combined with other conditions while preserving existing contains and unless behavior.