Fix overly general typeclass in generated type annotations

[dillonkearns]

Functions using +, <, or ++ were incorrectly resulting in type annotations with plain type variables instead of constrained ones, producing code that doesn't compile.

Example

Elm.Declare.fn2 "addBoth"
    (Arg.var "a")
    (Arg.var "b")
    (\a b -> Elm.Op.plus a b)

Before (broken)

addBoth : a -> a -> a
addBoth a b =
    a + b

The Elm compiler rejects this:

-- TYPE MISMATCH

This `+` operator only works with `Int` and `Float` values.
But the type annotation says `a` which means ANY type.

After (fixed)

addBoth : number -> number -> number
addBoth a b =
    a + b

This applies to all three typeclass constraints:

Operator	Before	After
Elm.Op.plus a b	a -> a -> a	number -> number -> number
Elm.Op.lt a b	a -> a -> Bool	comparable -> comparable -> Bool
Elm.Op.append a b	a -> a -> a	appendable -> appendable -> appendable

When one operand is concrete, the constraint correctly narrows:

-- Elm.Op.plus a (Elm.float 1.0) generates:
addToFloat : Float -> Float -> Float

[miniBill]

Would love to see a compappend test too

[dillonkearns]

Would love to see a compappend test too

I tried adding a test, but since there isn't a way to use elm-codegen to generate a value of this type, it ends up not being a meaningful test case to just hardcode in the compappend type because it treats it just like a type variable. I agree it would be nice, but I think we would need an API that allows you to derive values of that type.