Abstract rules assessment and redesign

Several abstract PEG rules can be simplified. Also the use of some abstract rules in other rules is often questionable.

GeneralExpression

GeneralExpression:
  FunctionCall | VarReference | Expression | Or | Object | String | Null
;

GeneralExpression is used in comparisons only. Then what is the purpose of Object? Also it could be better named ComparisonExpression, ComparisonOperand or ComparisonParameter? Also Number and Boolean should be there on the left to avoid matching Expression and Or, respectively.

IfStatement

Do we need this really? It contains one (why not more) Statement rules. The Statement (abstract) rule contains these common rules: ObjectImports | VarTuple | FunctionDefinition | IfStatement | ObjectTo | Variable | Print

• ObjectImports and FunctionDefinition make NO sense.
• The need for IfStatement nesting is trivial.
• VarTuple and Variable in IfStatement can be implemented using two or more IfExpression or IfFunction.
• The only use cases that only make IfStatement useful could be ObjectTo and Print (conditional output). However, these are more thought for interactive immediate execution than for deferred execution and for immediate interactive execution conditions can be checked "manually". Only in potentially rare use cases these might be needed.

The least that can be done, is to replace Statement in IfStatement with IfStatementStatement: IfStatement | VarTuple | Variable | ObjectTo | Print; (ordering should be carefully checked).

Check all other abstract rules

Abstract rules can be reused but there is no obvious benefit to maximize their reuse (because no metamodel classes are generated for these rules). For example Parameter is reused in several different rules. But we also have VarTupleParameter, ScalarParameter, NumericScalarParameter, BooleanScalarParameter, IterableParameter and IfExpressionParameter. These an all other abstract rules should be revised, restructured and simplified. This is not only to remove unnecessary / irrelevant matches but to avoid strange accidental matches that will produce unexpected -> non-handled errors.