Use functions in gpb_compile instead of in gpb_parse and gpb_scan

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`](https://hexdocs.pm/gpb/gpb_compile.html) 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](https://github.com/bitwalker/exprotobuf/blob/36dc21c/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.