Add MessageType and EnumType on FieldDescriptorProto

[rayokota]

@mgravell , I'm looking for a .proto parser that I can use for https://github.com/confluentinc/confluent-kafka-dotnet/

It appears that the one in protobuf-net.Reflection is close, but I cannot seem to find a way to get the corresponding DescriptorProto for a given FieldDescriptorProto that references the message type.

I believe this PR will help, and also fixes #532

[mgravell]

In principle, I think this is fine. Thoughts:

1. These are mutually exclusive and different types; we should be able to overlap the two values - maybe a single object or IType field (probably the second), and use theField as EnumDescriptorProto; (or whatever) for the setter?
2. Needs a test to show that they work as intended in at least one scrnario

[mgravell]

A small part of me is worried about conflicts on the API related to schema additions. I've been careful not to pollute the public API of these types for that reason. I wonder if what we should do here is something like:

internal IType UnderlyingType {get;set;}
// or ResolvedType - naming is hard!

on the field, and have separately some extension methods:

public static DescriptorExtensions
{
    public static EnumDescriptorProto GetEnumType(this FieldDescriptorProto field)
        => field?.UnderlyingType as EnumDescriptorProto;
    // etc
}

This guarantees that we're not hosed if Google ever add conflicting members. Thoughts?

[rayokota]

A small part of me is worried about conflicts on the API related to schema additions. I've been careful not to pollute the public API of these types for that reason.

Yes, I like your approach of using extension methods very much. I'll give it a shot when I get a chance, unless you want to do it first :)

[rayokota]

@mgravell , I made the changes as you requested. Please take a look. Thanks!

[mgravell]

Rerunning tests; SO18695728 failed but that is unrelated to your changes, so presumably something unstable in there that I need to fix separately. Will merge if test re-run voodoos that away.

Thanks; nice changes; it shouldn't be part of this PR, but: I wonder if we can simplify some of the code-gen code by using this new member.

[mgravell]

Actions on me:

1. Investigate flakey SO18695728
2. Investigate using new member in code-gen (removes dictionary?)

[rayokota]

Awesome, thanks for the quick turnaround! 👍