consolidate ValueType and ExprType

[clintropolis]

Description

Follow-up to #9638, this PR changes the expression system to operate on ValueType instead of ExprType. There should be no side-effects from this change, even though ExprType was missing FLOAT and COMPLEX, because ExprType was typically used to control explicitly supported types and otherwise explode. Input types are currently detected from the type of object when resolving identifiers, so there isn't risk of these unhandled types leaking into the expression system. A method toExpressionType has been added to convert a ValueType into the types which the expression system does understand (float into double, complex into an exception), for the SQL planning layer to use, (this was pushed down from Expressions utility class).

The only strange-ness introduced in this PR is that when implementing expressions we should ignore these unhandled types, but it seems worth it for having a single type system enum to use in all layers, as well as being able to share the utility methods available on ValueType.

---

This PR has:

• been self-reviewed.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[jihoonson]

LGTM

[gianm]

Because the expression system doesn't support all of the normal Druid ValueTypes, it might actually be better to keep them separate, since it makes things more type-safe. (We know that if we have an ExprType, then that represents a ValueType that the expression system can handle.)

[clintropolis]

Because the expression system doesn't support all of the normal Druid ValueTypes, it might actually be better to keep them separate, since it makes things more type-safe. (We know that if we have an ExprType, then that represents a ValueType that the expression system can handle.)

Yeah, I think long term we definitely do want to consolidate these, but maybe I am jumping ahead a bit and we should wait until Expr can handle all ValueType. I will close this PR for now.