Add root_module and wrap_in_module options

[chih-hung]

• When root_module=true do not emit code that fails to compile
  as a root module.
• When wrap_in_module=name is given, add a wrapper around output:
  pub mod name { ... }
  This allows the output file to be "included" and compiled.

[chih-hung]

The root_module option could be used to solve issue #493
The wrap_in_module option was the proposed workaround for issue #117

[stepancheg]

hi Chin-Hung, can you provide a more detailed example of how to is supposed to work?

Generally, I'm currently working on version 3 release, and it would be great if we could finally solve this issue, make some solution which should work fine by default.

[chih-hung]

I imported protobuf-codegen to the Android platform and used it as a plugin with Android's port of protoc. Android build system does not call cargo to build. It calls protoc to compile protobuf files into Rust files and calls rustc to compile the generated files.
One of my case uses the include! macro to include the generated file into into another file to compile. This has compilation error of issue #117, and needs to use the option wrap_in_module=some_module.
Another case generates a rust file and compile the file as a root module into a library to link with other rust code. This has compilation error of issue #493, and needs the option root_module=true.

[clintfred]

Not sure if this is related. I am still using the workaround I stated here to wrap my generated code in modules. When upgrading to 2.17 that solution broke because of the addition of

#![rustfmt::skip]

which according to rust-lang/rust#5472 is only allowed at the top level. My interim solution is to remove the skip directive from the generated code.

Maybe there's a better way of generating code inside of modules now, or maybe that's what this PR is about?

[stepancheg]

To handle generated code we agreed to proceed with #525. @clintfred have a look and tell what you think (if you have something to say) before that option is ported to the stable branch and released.

This PR is obsolete now.

[chih-hung]

Yes, I agree that #525 can replace this PR.