Support alternative filtering mode in recursive edge traversals

[obi1kenobi]

When applying filters in a scope marked @recurse, order of operations matters. There are at least two options for it:

1. Fully recurse first, then filter — this results in reaching child vertices even if intermediate steps did not satisfy the filtering condition.
2. Filter at each level of recursion — this results in pruning the recursion as soon as the filtering condition is no longer satisfied, and ensures all returned results were reachable along paths where each step satisfied the filtering condition.

The compiler's current choice of semantics is option 1. However, the option 2 has its uses as well, and is not implementable (not even as a post-processing step) as a function of the first, so an additional query-language-level feature appears to be warranted here.

Option 2 may not be supported by all backends (e.g. MATCH). However, it is definitely implementable e.g. in SQL.

[obi1kenobi]

One way to support both options is to add an enum-typed field to @filter directives to set the recurse filtering mode. This directive field would only be valid to use immediately within the first non-type-coercion scope within the scope marked @recurse. The "non-type-coercion scope" part above is necessary because of cases like #785, where the scope immediately within the @recurse may be a type coercion. In that case, filters within the scope immediately within the type coercion are also able to set the recursion filtering mode.

This approach allows filters within the same recursion to be set to different recursion filtering modes, which is convenient and gives additional expressivity to the query.