Validate target type for all option fields, not just features

[jhump]

The code to verify that a feature field was only used on particular kind of element was features-specific. However, in protoc, it is not features-specific and applies to all option fields that have a targets option defined.

This PR is a bit complicated because I had to change the error handling of the *interpreter.fieldValue method (and the setOptionField method that called it, as well as numerous methods that it used). It previously either returned a value or an error. If it returned an error, it would be reported by the caller. Even in the previous iteration of the code, this was not optimal because it meant that we had to abort processing an option value after the first error, instead of being able to potentially report multiple errors in the same option. But now, since the targets usage really doesn't impact the rest of the processing of an option value, it seems weird to abort that processing just because of a target type usage issue.

So now, the *interpreter.fieldValue method handles the errors that come up and only returns a non-nil error if the handler returns a non-nil error. That means calling code can no longer rely on err == nil but must separately check that the other returned value is valid/non-nil.

This change is the cause for most of the change/churn in the code.

The actual change to target type validation is a net simplification, which is nice.

[jhump]

@emcfarlane, this is the reason I did the pre-factoring in #281, so we have coverage of the way the code can now keep going and return both a nil/invalid result and a nil error.

There are changes to the message literal processing that involved un-indenting a block of code (to improve the control flow with an if (...) { ...; continue } ... instead of if (...) { ... } else { ... }). So I'd recommend selecting "hide whitespace" when viewing the diff.