[enhancement][dslx] Tabular comparisons (including for tuples of boolean, one-hot cases) can be cumbersome in Rustic match syntax

[cdleary]

What's hard to do? (limit 100 words)

As described in this comment and its followups: #1909 (comment)

It's common to smash some boolean values together and make a table of how you want to handle the possibilities for that bit vector. We may want to consider better syntax for this.

(Aside: IMO ideally if we do add non-Rustic syntax there's a simple way we can describe a simple desugaring of it into a Rustic pattern match just as confirmation we're not adding anything too far afield.)

cc @proppy @ericastor @mikex-oss

Current best alternative workaround (limit 100 words)

As described in followup comments we have things like:

match one_hot(sel) {
  0b100 => 
  0b010 => 
  0b001 =>
  _ => fail!("impossible_if_original_was_one_hot", ...)
}

which should demonstrate conclusively to the optimizer it can use a one_hot_sel and constructs like

match (x, y, z) {
  (true, _, _) => ...
  (_, true, _) => ...
  (_, _, true) => ...
   _ => ...
}

which lower to priority selectors on individual boolean values being set and should optimize into a prio sel primitive selector, but the OP here suggests that if this is common enough we may want to consider streamlining it.

Your view of the "best case XLS enhancement" (limit 100 words)

Consider the addition of dedicated syntax for this (i.e. if we find it is quite common and the next-best-alternative is considered too burdensome given that frequency).

[proppy]

Related #1729