typechecker: Evaluate bound expressions only once

[cg-jl]

Now Jakt inserts declarations to save the bound expressions before
checking them, and uses the variable names to access the bound parts.
This ensures that the original expression isn't run more than once.

Fixes #1450.

To do this I had to remove support for bindings inside match cases, part of
a feature made by @robryanx in commit
abab871, since it both allowed for weird match use cases and made the solution to this
issue more complicated.

[alimpfard]

Seems like this breaks stage 2 🤔

[alimpfard]

This line needs an indent

[cg-jl]

Seems like this breaks stage 2

Yeah, I'm working on it. I've messed up some control flow based checks with producing CheckedBlocks manually.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[stale]

This pull request has been closed because it has not had recent activity. Feel free to re-open if you wish to still contribute these changes. Thank you for your contributions!

[cg-jl]

Sorry for the delay. The idea here was to wrap the resulting values from a guard or an if in a block, converting:

if some_computation() is Some(x) {
    do_something_with(x)
}

into:

{
   let _cached_result = some_computation()
   if _cached_result is Some(x) {
       do_something_with(x)
   }
}

This looks redundant in Jakt code, but internally the typechecker transforms the first snippet to something like:

if some_computation().has_value() {
   do_something_with(some_computation())
}

This was hard to fix at the codegen level because it was already receiving the duplicate expressions from the typechecking stage. I opted for doing this in the typechecker, then. But by doing this I didn't get the metadata for the wrapping blocks correct, and the branch analysis of the typechecker for reachable/unreachable stuff then bit me in stage 2.

I haven't been able to get this metadata correct and I don't think it would be good anyway, I think it would be better to somehow generate parsed expressions again and let the typechecker expand on it, or generate those parsed expressions earlier in the parsing stages.

I will be leaving this as closed, I've become burnt out after trying seemingly incoherent modifications to solve the stage 2 problem.