Merge #1367

1367: Initial support for matches on tuples r=dafaust a=dafaust

Initial work on supporting more complex match expressions, starting with tuples. It's proven to be quite a bit more complicated than I originally expected. Still this implementation is very naive, probably very poor performance, and skips all the nuanced stuff like bindings in patterns and pattern guards.

Overview
The general idea is that we lower `MatchExpr`s to `SWITCH_EXPR` trees, but a switch can only operate on one value at a time. When scrutinizing a tuple, we can't build a switch that checks all the elements at once. So instead, just before lowering to trees, we construct a new set of nested match expressions which tests the tuple one element at a time, and is (hopefully) semantically identical to the original match. These new nested matches are simplified, so that each one tests only one thing and therefore *can* lower directly to a `SWITCH_EXPR`.

To see an example, this
```text
match (tupA, tupB, tupC) {
  (a1, b1, c1) => { blk1 }
  (a2, b2, c2) => { blk2 }
  (a1, b3, c3) => { blk3 }
  ...
  _ => { blk4 }
}
```
after one step becomes
```text
match tupA {
  a1 => {
    match (tupB, tupC) {
      (b1, c1) => { blk1 }
      (b3, c3) => { blk3 }
      ...
      _ => { blk4 }
    }
  a2 => {
    match (tupB, tupC) {
      (b2, c2) => { blk2 }
      ...
      _ => { blk4 }
    }
  }
  _ => { blk4 }
}
```
Repeat until all matches are fully simplified, then compile it all into trees.

Now, we might end up with a lot of duplicated basic blocks here as a result, but the optimization in GENERIC and GIMPLE (further on in gcc) is very good and knows how to take care of that for us.

This approach seems somewhat similar to how rustc lowers HIR to MIR, which is hopefully a good sign :)

Addresses: #1081

Co-authored-by: David Faust <david.faust@oracle.com>

0 files changed, 0 insertions, 0 deletions