Divide (closed) Primitives and (opened) Builtins

Splitting ElmPrim into:

ElmPrim - language level constructs
ElmBuiltins - types defined by libraries (not generated by elm-street) like elm/core or elm/time etc.

ElmPrim keeps its original closed design using variants in sum type.

ElmBuiltins is using record/product to make implementation open. This gives elm-street several new features:

user definable Elm instances for types provided by library
ability to define Elm instance for parametrized type at least in manual fashion.

Full vocabulary of ElmDefinition:

DefPrim - primitive types defined by elm (language itself - not just by core or other lib)
DefBuiltin - ADTs not generated by elm-street (provided by libraries like core or time).
DefRecord - record types
DefType - ADTs generated by elm-street

Example definitions

-- simple type instance
instance Elm Value where
    toElmDefinition _ = DefBuiltin $ ElmBuiltin
        { builtinImplType = "Value"
        , builtinImplEncoder = "Basics.identity"
        , builtinImplDecoder = "D.value"
        , builtinImplParams = []
        }

-- parametrized type instance
instance (Elm a, Elm b) => Elm (Either a b) where
    toElmDefinition _ = DefBuiltin $ ElmBuiltin
        { builtinImplType = "Result"
        , builtinImplEncoder = "elmStreetEncodeEither"
        , builtinImplDecoder = "elmStreetDecodeEither"
        , builtinImplParams = [elmRef @a, elmRef @b]
        }

Future work to be done

[ ] printing functions do produce valid elm code by are naive (produce trailing white-spaces)
Elm.Generate module should be extended to make it simpler to include custom imports into generated files. (future PR)

Possibly further extensions:

support for phantom types (labeling params as regular or phatom params)
in case we would be able to derive this, this can completely replace ElmType giving it support for parametrized types.

Related issues:

this will become avoidable https://github.com/Holmusk/elm-street/issues/113
user can make own tradeoffs and implement https://github.com/Holmusk/elm-street/issues/26

related closed issues:

things like this would be in user's control https://github.com/Holmusk/elm-street/issues/102
https://github.com/Holmusk/elm-street/issues/111
https://github.com/Holmusk/elm-street/issues/27

@jhrcek This is not ready for merge but I figured it would be better to get your feedback as soon as I have working spike. Please feel free to comment. This PR resolves my single biggest frustration of working with elm-street.

@arbus I think you might also give input to this proposal

Holmusk / elm-street