Differentiate between built-in and custom options, custom ones get parens

@JakeWharton

This is deep yak-shaving territory.

If I understand the Google Protobuf Documentation on [Custom Options](https://developers.google.com/protocol-buffers/docs/proto#options), we need to wrap custom options in parens, but leave the built-in ones paren-free.

> ```protobuf
> import "google/protobuf/descriptor.proto";
> 
> extend google.protobuf.MessageOptions {
>   optional string my_option = 51234;
> }
> 
> message MyMessage {
>   option (my_option) = "Hello world!";
> }
> ```
> Here we have defined a new message-level option by extending `MessageOptions`. When we then use the option, the option name must be enclosed in parentheses to indicate that it is an extension.
Yeah `isParenthesized` makes a ton of sense. The visibility of the enum was just an oversight.

> On Jul 12, 2014, at 10:20 PM, Jake Wharton <notifications@github.com> wrote:
> 
> In src/main/java/com/squareup/protoparser/Option.java:
> 
> >  
> > -  public Option(String name, Object value) {
> > +  enum Source {
> > +    BUILTIN,
> > +    CUSTOM,
> > +  }
> > +
> > +  public Option(String name, Object value, Source source) {
> For this to be in the constructor the enum has to be public as well. There's this weird disconnect where this library only knows about parsing and not the semantics of what some of these things mean. Maybe we just do boolean isParenthesized here instead?
> 
> —
> Reply to this email directly or view it on GitHub.