Support :test, variable binding expressions inside ops expressions

[alex-dixon]

This may be our first breaking change. The DSL is not grammatically consistent. For one, the syntax within :or, :and, :not and :exists blocks is not currently the same the same as writing rule expressions outside the context of those operators. We could leave it like this, but it seems better to be consistent overall.

Example of current syntax:

[:not [_ :foo "bar"]]

Proposed change:

[:not [[_ :foo "bar]]]

This would make it possible to parse the following without handling a special case of tuple expressions and all other expressions being nested within a single vector:

[:or [[_ :some "tuple"]]
      [:test (> 1 2)]]

The motivation for not doing this in the first place was to cut down on the number of brackets, but I am seeing this now as less important than logical consistency. Unfortunately, we would still be inconsistent in other areas, and need to add still more brackets and introduce more breaking changes:

; Current
[?fact <- (acc/all) :from [_ :foo "bar"]]
; Proposed
[?fact <- (acc/all) :from [[_ :foo "bar"]]

In isolation, there's no benefit to the this proposal here: Neither we nor Clara support an expression that is not a tuple expression to the right of an accumulator. The brackets are completely extraneous.

Equally:

; Current
[?fact <- [?e :attr ?v]]
; Proposed
[?fact <- [[?e :attr ?v]]]

Again, though this would achieve overall consistency, 2 brackets are redundant here for the same reasons as before.

Given this, we might approach consistency the other way: Double bracket tuple expressions are the odd man out. This may bring us closer to a solution--and with fewer brackets to boot. parse-as-tuple requires [[e a v]] as an argument. This appears needless. Further, parse-as-tuple is the default case for rewrite-expression--when we can't determine the expression is some other kind, we assume/infer it's a tuple anyway. Realistically, the lang specs for expressions don't appear to overlap, so we could probably accurately determine a tuple expression directly if we needed to.