Use functions in gpb_compile instead of in gpb_parse and gpb_scan

[tomas-abrahamsson]

I consider the functions in :gpb_parse and :gpb_scan to be internal to gpb, but exprotobuf uses them for parsing. I'm intending to change gpb_parse and gpb_scan in an upcoming rewrite of the parser, and would ideally like to avoid keeping functions for backwards compatibility in modules internal to gpb, and instead keep the api in :gpb_compile stable.

However, the functions in :gpb_compile, do currently not support the way exprotobuf splits protos into different modules as described in the imports_upgrade_guide.md. The way gpb currently handles things is to try to get one fully resolved set of proto definitions (imports and all) and generate one module from that. I'll try to think if there is some way to make change gpb to better support this use case though, and I am open for discussions.

(If it had not been for this splitting into different modules, I think the :gpb_compile:file(..., [:to_proto_defs] ++ options) would have been a working replacement.)

For reference, this originated from #112.

[tomas-abrahamsson]

One idea is to use the {{msg_containment, "⟨.proto⟩"}, [⟨msg name⟩, ...]} and {{enum_containment, "⟨.proto⟩"}, [⟨enum name⟩, ...]} elements that are present in defs. (the file names are Erlang strings, not binaries, sorry about using Erlang notation, don't know how to express this in Elixir syntax) There are also other ⟨x⟩_containment elements for services, rpcs and packages, when such definitions are present.

Another idea is to use the {file, {"⟨.proto base (-ish) name sans ext⟩", "⟨.proto base (-ish) name⟩"}}. The definition elements following such a file element all belong to that file:

a.proto: -------------
syntax="proto2";
import "b.proto";
message MsgA { required uint32 f1 = 1; }

b.proto: ------------
syntax="proto2";
message MsgB { required uint32 f2 = 1; }

1> gpb_compile:file("/path/to/a.proto", [to_proto_defs, {i,"..."}]).
{ok,[{proto_defs_version,1},
     {file,{"a","a.proto"}},            % --,
     {{msg_containment,"a"},['MsgA']},  %   | definitions
     {{enum_containment,"a"},[]},       %   | pertaining
     {syntax,"proto2"},                 %   | to a.proto
     {import,"b.proto"},                %   |
     {{msg,'MsgA'},[⟨field f1⟩]},       % --'
     {file,{"b","b.proto"}},            % --,
     {{msg_containment,"b"},['MsgB']},  %   | definitions
     {{enum_containment,"b"},[]},       %   | pertaining
     {syntax,"proto2"},                 %   | to b.proto
     {{msg,'MsgB'},[⟨field f2⟩]}]}      % --'
2> 

The .proto base (-ish) name means the name can contain trailing parts of the directory if needed to make them unique. For example when a proto imports both dir1/x.proto and dir2/x.proto.