More complex pattern matching in match statement.

[gerau]

Closes #240 and #241.

Implementing this was easy enough, because we already have the logic for this pattern matching in assignments, so we simply reused it. Also existing logic allows us to use _ for unused variable.

[stringhandler]

utACK

[schoen]

I haven't reviewed the implementation, but I did test this with my specific motivating use-case

fn amount_equal(a_amt: Amount1, b_amt: Amount1) -> bool {
    match a_amt {
        Left((a1, a2): (u1, u256)) => {
            match b_amt {
                Left((b1, b2): (u1, u256)) => {
                    and(jet::eq_1(a1, b1), jet::eq_256(a2, b2))
                },
                Right(b: u64) => false,
            }
        },
        Right(a3: u64) => match b_amt {
            Left(b: (u1, u256)) => false,
            Right(b3: u64) => jet::eq_64(a3, b3),
        },
    }
}

fn asset_equal(a_asset: Asset1, b_asset: Asset1) -> bool {
    match a_asset {
        Left((a1, a2): (u1, u256)) => {
            match b_asset {
                Left((b1, b2): (u1, u256)) => {
                    and(jet::eq_1(a1, b1), jet::eq_256(a2, b2))
                },
                Right(b: u256) => false,
            }
        },
        Right(a3: u256) => match b_asset {
            Left(b: (u1, u256)) => false,
            Right(b3: u256) => jet::eq_256(a3, b3),
        },
    }
}

and it worked great empirically. I also tested the _ with e.g. Left((_, _): (u1, u256)) => false and that worked too. (We can actually do either Left(_: (u1, u256)) => false or Left((_, _): (u1, u256)) => false and both work, yay!) So, everything I was hoping for appears to work well with this PR.

It's still too bad that we don't have a cleaner way to test equality of complex data types (see #245), but this makes these functions a lot more readable than they were before.

[schoen]

I've written some documentation for this which we can merge at the same time as we merge this PR.

BlockstreamResearch/simplicity-lang-org#41

This also inspired #250 as a further (more difficult) feature request related to match.