[Initial Feedback] New `like` and `match` keywords

I have been thinking that comparisons using new `like` and `match` keywords would be a natural extension.

The `comparator` rule would be extended like so:

```abnf
comparator =/ "like" / "match"
```

Are these features that would be of interest?

## Like

`` items[? foo like '**/*.json' ] ``

The `like` comparator would match simple SQL-like, wildcard-like or glob-like patterns.

I have investigated adding such contextual keywords to the language and found that it would probably easier with lex/yacc-based implementations, Nevertheless, using the top-down parser approach, one [simply has to account for those keywords](https://github.com/jmespath-community/typescript-jmespath/blob/3cf5ff9010ccaa26c27140b2312ce9eee235f498/src/Parser.ts#L84-L99) between the `nud()` and `led()` calls in the main parsing loop.

This makes the parsing algorithm less "pure" but I’m pretty sure more knowledgeable people might come up with more elegant designs.

## Match

The `match` comparator would match simple regular expressions.

`` items[? foo match 'ba[rz]' ] ``

I know that regular expressions have been a touchy subject in the past but I strongly believe we can make this work for JMESPath with:

- A narrow focus on _matching only_, _unanchored_ expressions. That is, the expression returns `true` or `false`.
- Restricting the syntax to a tiny but useful [subset of interoperable syntax](https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html).

I have come up with a prototype for a [reference implementation](https://www.npmjs.com/package/@springcomp/iregexp) of a simple push-down automaton-based checker and the implementation is [reasonaly tight and compact](https://github.com/springcomp/iregexp/blob/main/src/Checker.ts).

I believe most languages in which a JMESPath implementation exists do indeed support the interoperable subset.
The idea from the standazdization document referred to above is to:

1. First check that the syntax is valid.
2. Maps the interoperable regex to one compatible with the target implementation.
3. Execute the target implementation expression.

The standardization documents lists mappings for ECMAScript, PCRE, RE2, Go and Ruby dialects.

Once relying on such a compact library, the implementation is in fact [really easy](https://github.com/jmespath-community/typescript-jmespath/blob/3cf5ff9010ccaa26c27140b2312ce9eee235f498/src/TreeInterpreter.ts#L200-L217).

Start with the comparator grammar shown in the issue and the linked Parser.ts and TreeInterpreter.ts sections in the TypeScript implementation. Review the linked interoperable regular-expression proposal and prototype before deciding whether the syntax and matching semantics are accepted. Done requires an agreed design for both keywords and implementation guidance across supported JMESPath implementations.

Written by the indexing model from the issue text.