API change: values that are produced by the compiler should not implement protoreflect.Descriptor

[jhump]

For long-term future compatibility with the protobuf-go repo, the results of compilation should not return values that implement/extend protoreflect.Descriptor.

The values should instead implement a parallel hierarchy of interfaces (which very well might look almost identical to protoreflect.Descriptor). To actually use the values as protoreflect.Descriptor instances (like for dynamic message use cases), the returned values should provide a way to recover such a value to allow easy conversion. This could be via a method that might look like Unwrap() protoreflect.Descriptor (exact method name TBD) or, more likely, may be more strongly typed, such as Unwrap() protoreflect.FileDescriptor as a method on the file representation and Unwrap() protoreflect.MessageDescriptor as a method on the message representation.

I think it would likely be better to have this mechanism be provided by methods on model types, instead of a separate converter/resolver type or other top-level functions, to make it easier for the protoreflect.Descriptor instances to be memoized -- each element in the model could remember its corresponding descriptor, once built.

This should be done before this repo is deemed "stable" and tagged with a v1 release, to ensure that no future change in this repo nor in protobuf-go can lead to compatibility-based disruption.