WIP: Add Option to Drop Deprecated Messages and Fields

[jalandis]

Overview

Adds a new protobuf plugin option to ignore all deprecated fields + messages.

--elm_opt=remove-deprecated

Other changes:

• Switches to GO templating
• Upgrades dependencies + switches to GO modules
• Refactors using recommended GO package structure]

Driving Use Case

Deprecating an API field requires the removal of all references from the frontend code base. It would be nice to rely on compile-time errors to enforce this required deprecation.

Example protobuf with deprecated fields + messages.

message Bar {
    bool field = 1;
    bool deprecatedField = 2 [deprecated=true];
}
  
message Foo {
    option deprecated = true;

    bool field = 1;
}

[jalandis]

@thematthopkins @jonpitch
I have prepped this Test PR with some ELM PB plugin changes I have been working on in my free time. It's in a pretty good place right now and I was hoping to get your feedback on the new feature and design changes. Of course, no pressure if you're busy or uninterested.

Interested in any feedback you have but a few specific items I have been noodling:

• Any improvements to the type definitions
• Any recommendations for the new GO elm package design (better encapsulation, etc)
• Any recommendations on the project file structure
• Any recommendations on the build scripts

Depending on feedback, I will prep a real PR for the main project and maybe pull it into our build system.

[jalandis]

The change to the supported GO version technically makes this a backward-incompatible change. Not sure if that is important for the project as it is a standalone executable. Just in case that does matter, it might be nice to include a few other breaking changes before any new release.

1. Nested oneof values - the same solution for enums could be used (name collisions tiziano88/elm-protobuf#8)
2. Name collisions with multiple files (Incorrect code generated with type names tiziano88/elm-protobuf#28)
3. Optional decoders should fail with bad data (https://github.com/tiziano88/elm-protobuf/blob/master/tests/Main.elm#L43)

        ...
        , describe "better required"
            [ test "Decode required field with bad data" <| \() -> JD.decodeString (required "fail"  JD.int 0) badData |> Expect.err
            , test "Decode missing required field" <| \() -> JD.decodeString (required "succeed" JD.int 0) badData |> equal (Ok 0)
            ]
        ]


required : String -> JD.Decoder a -> a -> JD.Decoder a
required name decoder default =
    JD.maybe (JD.field name (JD.succeed Nothing))
        |> JD.andThen
            (\r ->
                case r of
                    Just _ ->
                        JD.field name decoder

                    Nothing ->
                        JD.succeed default
            )


badData : String
badData =
    """{ "fail": "wrong type" }"""

New decoder is similar to elm-json-decode-pipeline solution
https://github.com/NoRedInk/elm-json-decode-pipeline/blob/1.0.0/src/Json/Decode/Pipeline.elm#L111