prost-derive: Add #[(prost(prost_path = "::prost")]

[jeremija]

Add a new proc_macro attribute in prost-derive, which is used to let the macro implementation know about the value of
prost_build::Config::prost_path.

As a result, the derived messages no longer have ::prost hardcoded in them, and the configured path to th prost crate will be referenced everywhere in the generated code.

This change also adds support for configuring the path to
::prost_types via prost_build::Config::prost_types_path.

Fixes #939

[jeremija]

I didn't realize there was already #488 which basically does the same thing, and adds additional fix for prost_types.
I'd really want to get a fix for the original issue merged and fixed, so please let me know if there's anything I can do to help.

[chris-zen]

Do you have any plans to move this or #488 forward? I'm looking to wrap prost in my library so users don’t need to worry about the correct version—they can just rely on my library instead.

[jeremija]

I've updated this MR to also include the ability to re-export prost_types if desired. Also added a separate test crate to ensure the re-exports work as intended.

[demurgos]

I have an issue at work where my binary crate depends on two libs working with generated Prost code, except they use different major versions of Prost. With the hardcoded prost path, I can't fix it and have to wait until they update to the same version. However, any time a new Prost version is released and the libs get out of sync I'm back to being stuck.

With a way to override the path, I could use cargo to depend on both dependencies:

prost014 = {package="prost", version "0.14"}
prost015 = {package="prost", version "0.15"}

And it would avoid global coordination issues.

This PR would solve this issue neatly. 👍