Consistently support compound equality in the IR

[nanavati]

While working on #380 it has become clear that supporting compound equality (arrays, tuples and combinations of them) is not just a JIT problem.

For example, optimizations like arithmetic simplification assume the arguments of Eq comparisons in the IR are just simple bit vectors:

xls/xls/passes/arith_simplification_pass.cc

Line 518 in 24046e4

if (n->op() == Op::kEq && n->operand(0)->BitCountOrDie() == 1 &&

Similarly, the IR verifier currently doesn't allow Eq comparisons on non-bit things:

xls/xls/ir/verifier.cc

Line 507 in 24046e4

absl::Status HandleEq(CompareOp* eq) override {

The reason we can get to the JIT at all with a compound equality is that test constructs aren't consistently converted to IR and verified.

We should have a consistent story about how to handle compound equality in the IR. Options include

1. Always desugaring compound equality as part of converting to IR. (Pro: Simplifies IR handling downstream, Con: Desugared equality means we lose high-level structure and could turn into more complex and less readable generated Verilog).
2. Requiring all IR tools to hand compound equality (Pro: We don't lose the underlying equality structure. Con: Extra complexity in everything that handles equalities in IR).
3. Context-dependent switching between desugaring or not (maybe via a flag, maybe based on what downstream consumers are). Pro: Can do the most convenient thing for different use cases. Con: Extra complexity (especially because some IR invariants become weaker).