Improve type errors

[jfecher]

The current type errors given by the compiler are largely placeholders - there is much room to improve.

Examples:

foo x = x
foo 0 1

// error:
// foo.an: 4,1	error: Function types differ in argument count: (a -> a) (1 arg(s)) and (a - b => d) (2 arg(s))
// foo 0 1

This error could use an extra "note" pointing to the definition of the function in question.

---

foo (x: bool) = x
foo 0

// error:
// foo.an: 2,5	error: Expected a primitive integer type, but found bool
// foo 0

This error would be more readable as an argument type mismatch error, but instead 0 incurs an Int constraint and the compiler tries to solve for Int bool, producing this error message when it fails. Again, pointing the definition (and type signature) of foo can help here.

---

foo (x: Maybe i64) = x
foo (Some false)

// error:
// foo.an: 2,1	error: Type mismatch between bool and i64
// foo (Some false)

A more specific error message would be useful here. Something along the lines of "Expected parameter of type ..., but found argument of type ..." It would also be useful to give users the entire types rather than just the mismatching portions - while highlighting only the portions that don't match in red. For example "Expected parameter of type Maybe i64, but found argument of type Maybe bool". This would require us to delay the error in try_unify_with_bindings until the topmost recursive call when we have the entire type. Then we'd need some version of TypePrinter which prints the diff of two types.

Another useful thing to have here is some form of checking how long the the types are. If they are past a certain length we should split the message on two lines and align the types for better readability as so:

// foo.an: 2,1	error: Type mismatch between
// parameter MyReallyVeryQuiteTheLongType (Maybe (Maybe bool)) and
// argument  MyReallyVeryQuiteTheLongType (Maybe (Maybe i64))
// foo (Some false)

---

Lastly, we can also experiment with improving error messages by changing the formatting slightly. Ante's current formatting is optimized towards short error messages that take up only 2 lines. Readability can be hurt by longer file paths however. We may consider some alternatives instead:

/home/myuser/code/ante/myproject/bar/foo.an: 2,1	error: Type mismatch between bool and i64
foo (Some false)

/home/myuser/code/ante/myproject/bar/foo.an: error Type mismatch between bool and i64
2| foo (Some false)

error Type mismatch between bool and i64
/home/myuser/code/ante/myproject/bar/foo.an:
2| foo (Some false)

It may also be the case we want to dynamically check the length of the file name and switch between the second and third cases as necessary.

[jfecher]

The low hanging fruit of this is addressed as part of the hashmap branch that has been merged. We can always improve type errors further but it'd require more investigation that make the rest of this no longer a good first issue