Fix data race in compiler when resolver provides unlinked descriptor proto

[jhump]

From looking at the data race errors in bug report #102, this can happen only if a *descriptorpb.FileDescriptorProto or parser.Result is provided as a search result and is shared across parallel compiler operations.

So, luckily, that means many (most?) usages of the compiler are safe, including the way that buf uses it.

This looks to have always been the case. But I bet the user described this as a new failure because their tests previously didn't all share a search result for "google/protobuf/descriptor.proto". But as of #97, all compile operations will implicitly use a search result for this file. So I suspect the reporter's tests use a resolver that returns a proto for this file and previously only one of the tests actually used it (i.e. only one test actually imports that file).

This is a non-trivial change mainly because I was worried about the performance impact of always cloning values, even if it's not necessary. So the strategy here is to only make a defensive clone of the descriptor proto (or the parser result, which contains a potentially mutable descriptor proto) when necessary. How do we know if it's needed? If it has any type names that are not fully-qualified (field extendees, field types, method input and output types), if it has uninterpreted options, or if it has no source code info but needs it. Under these conditions, the compiler will mutate the proto (to make type names fully-qualified, to interpret options, to add source code info).

Edit: The code now always clones descriptor protos and parser results (which may contain a descriptor proto). That way there's no worry of the mutation logic getting out of sync with the logic that decides whether or not to clone.

The most complicated bit here is actually cloning a parser result, and associated tests, because it has an index that maps elements in the descriptor proto to their corresponding AST nodes. So we have to rebuild that index so it matches the new (cloned) elements in the descriptor proto.

The test added to compiler_test.go successfully reproduces the data race that was reported and is fixed with all of the other changes in this branch.

Fixes #102.

[pkwarren]

A bit concerned with the complexity around clone and also with any possible missed mutations in the checks to determine if we need to clone the parse result or descriptor proto.