Add opt-in support for unknown fields

[andrewhickman]

Adds a new option to prost-build:

     .include_unknown_fields(".my_package.MyMessage", "unknown_fields");

which adds an extra field to the generated code:

#[derive(prost::Message)]
struct MyMessage {
  #[prost(uint32, tag = "1")]
  foo: u32,
  #[prost(unknown)]
  unknown_fields: prost::UnknownFieldSet,
}

When decoding the message, unknown fields are added to the new field.

The API of UnknownFieldSet is fairly minimal at the moment, it is mostly intended to allow roundtripping the fields

Closes #2

[andrewhickman]

I just noticed there was a previous, quite similar attempt at this in #117 . This is PR is a bit more conservative in that it doesn't change any existing messages, e.g. those in prost_types. I think its possible for consumers to work around that by using Config::compile_well_known_types though, if they really care.

[andrewhickman]

Reopening this since I noticed unknown fields were mentioned in #624 . I don't personally need this functionality any more but hopefully it can be useful as a starting point

[QuentinPerez]

Would like to revive this topic, just wanted to know what is missing here and how we can help with it.
It's starting to be critical for us. (Otherwise, we will have to rewrite some parts of our business in Go)

Q: Why not having unknown fields by default instead enabling them one by one ?
Edit: because it breaks the API as unknown_fields is required Message { .., unknown_fields: Default::default() }