Add additional structuring to Filter, Expression, and Literal

[devinrsmith]

The interfaces of io.deephaven.api.expression.Filter, io.deephaven.api.expression.Expression, and io.deephaven.api.value.Value were originally developed and influenced based on the structure of the gRPC messages and engine capabilities; and they were explicitly called out due to lack of completeness with respect to these constructions in #829, #830, and #831.

Upon delving into SQL work in #3473, it became clear that it was time to update these interfaces with the more expressive structures that could better preserve the semantics and intentions of the SQL expressions. The alternative involves throwing up our hands and using io.deephaven.api.RawString everywhere instead.

For example, it was possible before to represent the filters of Foo > Bar and Foo > 42, but it was not possible to represent Foo > Bar + 42 (again, without dropping down into RawString); and equivalently, an Expression could be Bar, or 42, but not Bar + 42 (essentially, limiting what could be represented in the case of view or update Selectable).

This PR greatly expands the expressiveness of these interfaces while also cleaning up the hierarchy. The main highlights:

• Filter is now an Expression
• FilterCondition renamed FilterComparison
• Value is gone; in its place, a more specific Literal structure
• Usages of Value replaced with the more generic Expression type (for example, LHS / RHS of FilterComparison are now Expressions instead of Values)
• ExpressionFunction created to represent function calls without needing to drop into RawString (for example, we might want to have io.deephaven.sql.Functions#sum_sql as something that can be properly referenced).

This PR does not aim to update the gRPC layer at this time, mainly do to time considerations and that #3473 is limited to execution completely within the server environment. That said, we would likely benefit from updating the gRPC layer to be more expressive in the ways proposed here.

There's also potential in the future for the engine layer to benefit from the additional structuring here; potentially constructing more advanced filters and expressions without needing to compile strings.

[rcaudy]

RHS of a match filter can be a QueryScope param. Literal is insufficiently inclusive.

[devinrsmith]

Okay - I'll expand this type b/c I agree. That said, there is room for a QueryScope extends Expression type in the future that we don't currently have.

[rcaudy]

You need to support FilterMatches in some way, but it could be via equals, in, and case-insensitive String-specific variants of each (4 total).
I still think you need param support.

[devinrsmith]

I think we should follow-up later w/ #3784

[devinrsmith]

And #3785

[rcaudy]

Expression seems too general. Why not ColumnName?

[devinrsmith]

We're trying to be as generic enough to capture the semantics that one could reasonably want to express (or express via SQL), even though our engine might not support it for now.

As a quasi example in our parser-like syntax:

Foo + Bar in "foobar"

[rcaudy]

We want to go to a ConditionFilter in this case; if we do a disjunction, we'll load the inputs N times.

[deephaven-internal]

Labels indicate documentation is required. Issues for documentation have been opened:

How-to: https://github.com/deephaven/deephaven.io/issues/2563
Conceptual: https://github.com/deephaven/deephaven.io/issues/2562
Reference: https://github.com/deephaven/deephaven.io/issues/2565
Blog: https://github.com/deephaven/deephaven.io/issues/2564