Improve ergonomics of ["contains"] expression

[anandthakker]

Quoting @jfirebaugh:

["contains", ["get", "type"], ["literal", ["primary_link"]]]

This seems overly clunky for a very common case. @anandthakker what do you think about two forms:

["in", needle, ...], where the varargs are required to be literals
["in", needle, haystack], where haystack is an array

Of course, writing it as ["match", ["get", "type"], ["primary_link", ...], true, false] is another option, and more efficient.

And a final option I'll throw out here: we could support a 2-arity form of match, ["match", input, [literals...]], which is syntactic sugar for ["match", input, [literals...], true, false]. This would be the recommended and most efficient form for when you're checking inclusion in a set of literals. "contains" would still exist, but you'd only want to use it when the second argument is not an array literal.

[1ec5]

In Objective-C and Swift, NSPredicate has a CONTAINS operator that serves as both an array search operator and a substring search operator (#4113), depending on the type of the first argument. It’s a convenient option even when a MATCHES operator exists for regular expression filters (#4089).

There’s also an IN operator that reverses the order of the arguments, both for array and substring searches.

[nickidlugash]

This sounds great 👍 Just adding myself to follow the conversation. /cc @aparlato

[jfirebaugh]

We removed contains in #5412; for the common case where the search array is a set of literal values, use ["match", needle, haystack, true, false] as suggested above instead.