Simplify kernel AND/OR logic

[ryan-johnson-databricks]

The variadic AND/OR code was more complex than it needed to be. We can simplify by allowing them to be empty, with well-defined default values (AND() == TRUE and OR() == FALSE), and also by defining static xx_from methods for building up lists.

While we're at it, replace most uses of Expr::binary and Expr::variadic with direct convenience methods.

NOTE: In the spirit of "don't optimize" this PR intentionally does not optimize the various degenerate cases that can arise. These include, but are not limited to (OR cases are similar):

• AND() --> TRUE
• AND(x) --> x
• AND(x..., FALSE, y...) --> FALSE
• AND(x..., TRUE, y...) --> AND(x.., y...)
• AND(x..., NULL, y...) --> AND(x..., y...)
• AND(x..., AND(y...), z...) --> AND(x..., y..., z...)

There are probably others as well. Rather than (try to) implement all of those optimizations, or guess which subset of optimizations is "most valuable", we choose to not implement any of them for now.

[roeap]

I think the change in LoC speaks for itself :).

👍

[roeap]

this is of course equivalent and less verbose. personally i have a slight preference for the more verbose syntax to favour consistency over brevity.

on the other hand this shows more clearly that is produces the same type ...

[ryan-johnson-databricks]

Yes, I went through the same questions and ultimately decided that type Output = Self makes clear enough that we're returning the same type, and that Output is only needed to satisfy the trait. Does that sound reasonable?

[roeap]

absolutely!