feat: add find_index, has, and reject filters

[brunodccarvalho]

Implement new collection filters find_index, reject and has to match ruby side. Fixes #798

[brunodccarvalho]

So the first issue is an inconsistent behaviour between where and find filters when undefined is given as the expected value. The where filter will detect undefined and filter for truthy entries, whereas find simply treats undefined as the literal value to grep for. Of course expected is undefined when it is omitted.

# data = [{ name: "Adamy" }, { name: "Blake", age: 50 }], xyz is not defined
{{ data | where: "age", xyz | json }} => [Blake]
{{ data | find: "age", xyz | json }} => Adamy

Consider the ruby implementation of find

From my understanding the first behaviour is roughly the (new) ruby behaviour, and the second is the jekyll behaviour. I imagine this inconsistency should be addressed, as find sounds like it should be functionally equivalent to where | first. Here find is changed to follow the first behaviour like the new filters. Can also consider a system option or checking arguments.length

[brunodccarvalho]

Ruby liquid detects null to search for truthy values, here we detect only undefined. I suspect this is not a big issue.

Now find and find_index are returning undefined on misses while ruby wants to return null. This was changed on #723. It becomes functionally different after one more step, like appending | json or something like this which outputs NaN or 0 depending on what find returns:

{% assign blake = data | find: "age", 30 -%}      # wrong age
{{ blake.age | times: 2 }}

[harttle]

Yes I agree we need find and where to be consistent, and returning null/undefined be consistent with liquid, at least in a way that it behaves same with one more step. Not sure if there’s any other consequences but we can have a try.
Checking arguments length sounds more intuitive but we need be consistent with shopify first (same template same result). We can have a jekyllFind toggle latter if someone has concrete cases.

[brunodccarvalho]

I think we can proceed as follows for the first issue: we have all these filters implement the ruby behaviour by default, and we overload this.context.opts.jekyllWhere to switch them all to the jekyll behaviour. All the variable logic can be compressed into the matcher function which is shared between the filters. This is backward-compatible for where with this.context.opts.jekyllWhere === false

Don't have a strong opinion about the other two deviations