Add #[non_exhaustive] option to enum codegen options

[danburkert]

It would be nice to be able to have a way to tag generated enums with #[non_exhaustive]. The feature is still in development, but once it's implemented and unstable, prost can in theory take advantage of it without requiring nightly.

[per-gron]

Is the plan to just add #[non_exhaustive] to the generated enums as they are today and keep the i32 storage, or to only have the enum directly in the generated structs?

It would be nice to use enums directly but the RFC says things that imply that it wouldn't be safe to do so: "Outside the crate that defines the enum, users should be required to add a wildcard arm to ensure forward-compatibility, like so: [match expression with default arm] And it should not be marked as dead code, even if the compiler does mark it as dead and remove it."

[per-gron]

I think I just found the answer to my own question in rust-lang/rust#36927 (comment) : even with #[non_exhaustive] it is wrong to ever have an enum with a value that is not specified in code so #[non_exhaustive] cannot be used to replace the underlying int storage.

[vlisivka]

#[non_exhaustive] is stabilized. Can we switch back to enum's now, please?

[danburkert]

To be clear, this issue is not about changing the representation of enum message fields. The current strategy of using i32s is here to stay. This issue is about applying the #[non_exhaustive] tag to the generated Rust enum types, and only on an opt-in basis via code gen builder arguments.