improvements to protoparse's handling of message literals

[jhump]

When a custom option's type is a message and the value is defined using a message literal, protoc parses the content of the message literal as the protobuf text format.

The protobuf text format has some quirks that were not previously handled by protoparse:

1. Unlike other places that refer to symbols, extension names in the text format may not begin with a dot to indicate they are fully qualified.
2. Boolean values can be specified using "t", "f", "True", or "False", in addition to the normal keywords which are all lower-case ("true" and "false").

Also, protoparse was not previously handling the case where an enum is defined with enum values whose names conflict with certain keywords ("true", "false", "inf", "nan"). The parser would see these identifiers and eagerly convert to bool or float values and then complain about their use with the enum. Instead, parsing should always represent these identifiers using identifier nodes in the AST (not bool or float literal nodes), and they can then be converted to bools/floats as needed. That way, if they need to instead be interpreted as enum value names, they can be.

[jhump]

I suspect protoparse's resolution of extension names that inside message literals may be more lenient than protoc. Protoparse is likely resolving them the same way it resolves other symbols (which means it uses the scope of where the reference is in the source to support partially qualified or unqualified references). But I think protoc always requires the fully-qualified name unless the unqualified name is unambiguous, in which case it is allowed.

TODO: test this more...

[jhump]

TODO: test this more...

Indeed, there are some fun discrepancies. I have fixes in another branch: see #484.