move each OperatorDefinition to its own Production

[OmarTawfik]

Originally posted by @OmarTawfik in #332 (comment):

In the current grammar, name here is the name of the parent expression node (that contains both the operator and operands). There is no way to define a name for the operator node.

- name: "UnarySuffixExpression" # name of parent node
  model: "UnarySuffix"
  choice: # cannot name the operator node
    - terminal: "++"
    - terminal: "--"

Moreover, this shape forces us to duplicate the entire base expression node for each version break in one of the operators. See #432 for example. I suspect these versions will only keep growing, making it harder to read, understand, and diff its contents.

I suggest moving the definition of each operator to its own Production (as a ParserRef, where it can be versioned separately. The main Expression.operators list can remain unversioned, unless a version actually adds/removes operators, or changes their precedence.

Additionally, this includes it in visit_parser visitor checks. We don't do that now, which is a bug.

pub struct OperatorDefinition {
    pub name: String,
    pub model: OperatorModel,
    pub operator: ParserRef,
}

This allows us to do:

- name: "UnarySuffixExpression"
  model: "UnarySuffix"
  operator: "UnarySuffixOperator"
  
- name: "UnarySuffixOperator"
  unversioned:
    choice:
        - terminal: "++"
        - terminal: "--"