Introduce a type hint system

[josevalim]

Instead of trying to assuming that a certain usage of a type is the correct one, we keep the unification message agnostic and add hints to the message.

Each message may have multiple hints, as they are computed alongside the trace. The traces are also reversed in order to keep the order they are added.

Here is how the new warning for dot access look like:

warning: incompatible types:

    map() !~ atom()

in expression:

    # a.ex:4
    module.__struct__

where "module" was given the type map() (due to calling var.field) in:

    # a.ex:4
    module.__struct__

where "module" was given the type atom() in:

    # a.ex:3
    %module{}

HINT: "var.field" (without parentheses) implies "var" is a map() while
"var.fun()" (with parentheses) implies "var" is an atom()

Conflict found at
  a.ex:4: A.a/1

And here is the hint for binaries:

warning: incompatible types:

    binary() !~ integer()

in expression:

    # a.ex:2
    <<foo>>

where "foo" was given the type binary() in:

    # a.ex:2
    is_binary(foo)

where "foo" was given the type integer() in:

    # a.ex:2
    <<foo>>

HINT: all expressions given to binaries are assumed to be of type
integer unless said otherwise. For example, <<expr>> assumes "expr" 
is an integer. Pass a modifier, such as <<expr::float>> or <<expr::binary>>, 
to change the default behaviour.

Conflict found at
  a.ex:2: A.a/1

[ericmj]

I like the removal of the uninteresting parts 👍