Allow generators which don't populate optional fields

[csboling]

What a great tool! I was glad to see that the protobuf descriptor API is close enough for Protobuf v3 that I was able to use protofuzz on the definitions from my Protobuf v3 project. In v3 all nested messages are optional, and we're making a lot of use of this to communicate "no value", but it seems that protofuzz wants to populate all fields. I messed around with it for a while and this implementation was the only way I was able to make it work, which is maybe less than ideal. In particular I'd guess that this behavior should be optional. I also haven't tested it against protobuf v2, where I think you would probably need a little more code to distinguish between required and optional messages.

[dguido]

Thanks! We'll take a look at this soon.

[csboling]

My patch is definitely functionally incorrect, issues I have discovered include:

• Some messages never produce more than a few permutations, e.g. one with and then one without a submessage
• Permutations which omit some submessages seem not to show up for >100,000 permutations in some cases, and then to come one after another

I'm not sure exactly what the issue is but the way I did it in the linked patch was kind of last-ditch. I wanted to use the Product combinator to make "don't descend into this submessage" a possibility but it seemed as though some of the code was built around the assumption that "values" to fuzz should be leaf fields/primitive types, not compound Protobuf message fields.