Implement codegen validation for (goes) option

[yevhenii-nadtochii]

This PR implements codegen-based validation of (goes) option.

In particular, it does the following:

1. Adds GoesPolicy, which emits the validation rule for the target field.
2. Adds positive tests for one-way and mutually dependent fields.
3. Removes (goes) from Workaround.kt file, and the runtime tests for this option.

The other aspects of (goes) feature are going to be addressed with separate PRs:

1. Error messages and tests for them – along with Extract common parts that generate code to create an instance of ConstraintViolation #167. There is some contradiction with how options treat default_messages and custom error_msg. It should be discussed and addressed.
2. Negative tests are to be implemented along with negative tests for (set_once).
3. Add more details to the option docs.

[codecov]

Codecov Report

Attention: Patch coverage is 13.79310% with 25 lines in your changes missing coverage. Please review.

Project coverage is 31.24%. Comparing base (4c1d9e9) to head (779ad9a).
Report is 30 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #168      +/-   ##
============================================
- Coverage     33.14%   31.24%   -1.90%     
+ Complexity      344      331      -13     
============================================
  Files           138      139       +1     
  Lines          2779     2797      +18     
  Branches        233      229       -4     
============================================
- Hits            921      874      -47     
- Misses         1795     1867      +72     
+ Partials         63       56       -7     

[yevhenii-nadtochii]

@armiol @alexander-yevsyukov please confirm specs for (goes) option. The present documentation doesn't say about the supported target (which declares the option) and companion (which is specified in with) field types.

The docs fragment from `options.proto`.

// Specifies that a message field can be present only if another field is present.
//
// Unlike the `required_field` that handles combination of required fields, this option is useful
// when it is needed to say that an optional field makes sense only when another optional field is
// present.
//
// Example: Requiring mutual presence of optional fields.
//
//    message ScheduledItem {
//        ...
//        spine.time.LocalDate date = 4;
//        spine.time.LocalTime time = 5 [(goes).with = "date"];
//    }
//
message GoesOption {

    // The default error message format string.
    //
    // The first parameter is the name of the field for which we specify the option.
    // The second parameter is the name of the field set in the "with" value.
    //
    option (default_message) = "The field `%s` can only be set when the field `%s` is defined.";

    // A name of the field required for presence of the field for which we set the option.
    string with = 1;

    // A user-defined validation error format message.
    string msg_format = 2 [deprecated = true];

    // A user-defined validation error format message.
    //
    // May include the token `{value}` for the actual value of the field. The token will be replaced
    // at runtime when the error is constructed.
    //
    string error_msg = 3;
}

In its docs, the option is compared to required and should likely mimic its behavior. So, I suggest the following list of supported target and companion fields:

1. Messages and enums. Default instances are considered to be non-set.
2. Repeated fields and maps. Empty collections are non-set fields.
3. string and bytes. An empty string and empty byte array are non-set.

The same field types are supported by (required).

Numeric and boolean fields are not intended to be either target fields or companions, as it is impossible to determine whether such a field was set or not. The (required) option also treats these fields as always set because their default values are quite "normal". The remaining question is whether we should silently ignore these fields when used with the option (as (required) does) or throw an error instead.

[armiol]

@yevhenii-nadtochii Yes, I would consider it to be like a conditional required. With the applications exactly like required has.

[yevhenii-nadtochii]

@armiol @alexander-yevsyukov PTAL

There is one nuance, which I initially overlooked in options.proto. The default error messages are configured using %s placeholders, but custom messages are configured using named placeholders like {fieldValue}. For IfSetAgain, I've used named placeholders in both the custom message and in the default one, not differentiating them when handling the message pattern in the implementation.

I suggest either align IfSetAgain with others or migrate others to behave as IfSetAgain. In scope of #167.

[armiol]

@yevhenii-nadtochii mostly LGTM. See my comments, though.

[armiol]

I would move it to .given package and rename to ...Env.

[armiol]

Same as above.

[yevhenii-nadtochii]

@armiol PTAL