Support equality/inequality and NULL comparisons for ARRAYs

[RobertBrunel]

This change adds the usual binary equality and inequality predicates for
ARRAY values, =, <>, and IS [NOT] DISTINCT FROM, and well as unary
IS NULL and IS NOT NULL predicates. To smoothly support comparisons
with the untyped empty array constructor (as in … WHERE <array> = []),
we also add appropriate promotion logic. For completeness, further
overloads are added to handle edge cases involving [] or NULL on both
sides (as in NULL = [] or [] = []).

Specifically:

• In AbstractArrayConstructorValue, allow the evaluation of []. This
  helps us avoid special logic in other places. Also fix the with()
  method so that it picks the correct element type.
• In EvaluateConstantPromotionRule, handle the constant promotion case
  from [] to a typed array.
• In MessageHelpers and PromoteValue, make sure the coercion logic
  for arrays can handle the "None" type smoothly.
• In RelOpValue, add the relevant UnaryPhysicalOperator and
  BinaryPhysicalOperator variants. Also add logic in evaluate() to
  promote the arguments to their maximum type if arrays are involved.
  This way we don’t have to define a multitude of operator overloads for
  mixes of ARRAY and NONE/NULL arguments.
• In Type#maximumType(), add the necessary logic for NONE.
• Use the SQLSTATE code 42804 when comparison operands are incompatible.

Out of scope:

• Comparisons of different ARRAY types such as [1I] = [1L]. If the
  element types can be promoted (here from INT to LONG), this could be
  supported in the future.
• Optimizing = [] further by handling it with a dedicated predicate.
• Constant folding for constant comparisons such as [1] = [].

Testing:

• New integration tests in arrays-operators.yamsql.

[hatyo]

LGTM