Add filter_expression_after_dot_notation query

[CraftSpider]

No clear consensus, and definitely an important difference to track I feel

[cburgmer]

I think there's another piece hiding in your query: The filter expression here operators on an object, if I checked correctly. There is https://cburgmer.github.io/json-path-comparison/#filter_expression_on_object which shows no consensus exists for that case. So this could be the reason for no consensus existing here either.

For the PR: we have already added complex queries in the past, but IMHO there should be a clear benefit not captured by some of the other simpler queries.

I'm happy to be proven wrong though, that is that this is not covered by https://cburgmer.github.io/json-path-comparison/#filter_expression_on_object.

[CraftSpider]

Rust's jsonpath_lib gives notably different results in this case - returning no items matching the query unless you add an intermediate [*]. The intended test here is not just how it behaves on objects, but what 'the current object' means after a dot operator on an object.

[CraftSpider]

Basically, some implementations seem to differ in their behavior when a filter on an object is done after selection on an object, and I think that's worth evaluating.

[cburgmer]

I'll have a fresh look on it when it's not the end of the day. I just realised that you packed a few things in there. I might dig up some of the other existing queries to show how this is different!

[CraftSpider]

Fair! I can see how this query is fairly non-atomic, looking at it again. I'll see if I can explain the results as a combination or the more atomic existing queries