`(every_is)` should not be overridden by `(is)`

[armiol]

Consider the use case:

// ...
option (every_is).java_type = "com.acme.effort.GoodDeedMixin";

// ...

message RosesPaintedRed {

    option (is).java_type = "com.acme.author.LewisCarrollMixin"

    // ...
}

What I expected was that RosesPainted received two interfaces, as it was indeed a good deed, and it was still related to Alice in Wonderland by Mr. Carroll. It looks obvious as "every" means "each one".

However, at the moment, the message-level (is) option overrides the file-level one. Hence, the generated class gets only LewisCarrollMixin.

Also, (is) does not seem to support several comma-delimited types. So the only way for me to achieve the goal is to create another interface deriving from both LewisCarrollMixin and GoodDeedMixin, and put it into (is) option. This is quite a linguistic task for me.

So, as this issue gets resolved, (is) on the message level should append the (every_is), not override it.

[armiol]

@dmdashenkov @alexander-yevsyukov FYI.

[alexander-yevsyukov]

Now this sounds reasonable to me. @dmdashenkov, how easy is this change?

[dmdashenkov]

I think we can do this.

Initially, the idea was that in such cases the user would create an interface LewisCarrollGoodDeed extended from the two others and pass it to (is). However, appending instead of overriding does sound more natural.