Unify type errors for patterns

[Zalastax]

As part of the effort of solving #49, #137 touched the error reporting for {var, _, _}. As @zuiderkwast writes, the error for expressions should not be the same as the error for patterns (we can't provide a good error description if they are the same).

What we need to happen:

• Expressions and patterns should have distinguishable error formats
• The error format for patterns should be agreed upon, possibly in the same way as its being done for expressions: one at a time
• The error format for expressions is already being worked on but it might need to be modified to distinguish them from patterns

[josefs]

What about an extra field in the error which indicated whether it comes from an expression or a pattern? Or do you have some alternative design in mind? It'd be good to have a concrete proposal to discuss.

[Zalastax]

@josefs I'll need to do some investigation to answer but my initial feeling is that it should be okay to do as you suggest. This issue basically served as a reminder.

I want the type for returned errors to be very precise so using a boolean had me scared initially. However, for the expressions which can't be patterns, we can eventually refine the type to only allow for false in those cases.

Stay tuned!

[zuiderkwast]

A while ago, I suggested this structure (though perhaps not exactly these atoms): {pattern_type_error, Pattern, ActualType, ExpectedType}, while for expressions keeping the current one {type_error, Expr, ActualType, ExpectedType}. How about that?

Perhaps there are other kinds of pattern type errors too, are there?