The main trick here was transforming Assignment
to contain `Vec<UntypedPattern, Option<Annotation>>`
in a field called patterns. This then meant that I
could remove the `pattern` and `annotation` field
from `Assignment`. The parser handles `=` and `<-`
just fine because in the future `=` with multi
patterns will mean some kind of optimization on tuples.
But, since we don't have that optimization yet, when
someone uses multi patterns with an `=` there will be an
error returned from the type checker right where `infer_seq`
looks for `backpassing`. From there the rest of the work
was in `Project::backpassing` where I only needed to rework
some things to work with a list of patterns instead of just one.
The 3rd kind of assignment kind (Bind) is gone and now reflected through a boolean parameter. Note that this parameter is completely erased by the type-checker so that the rest of the pipeline (i.e. code-generation) doesn't have to make any assumption. They simply can't see a backpassing let or expect.
We do not actually every parse negative values in there, as a negative value is a combination of a 'Negate' and 'UInt' expression.
However, for patterns and constant, it'll be simpler to parse whole Int values as there's no ambiguity with arithmetic operations
there. To avoid confusion of having some 'Int' constructors containing only non-negative values, and some being on the whole range,
I've renamed the constructor to 'UInt' to make this more obvious.
rvcas