ST6RI-533 Update implementation for 2022-04 baseline

[seidewitz]

This pull request implements updates to Root elements of the abstract syntax, per the 2022-04 baseline metamodel. It also makes updates to the implementation of invocation expressions, indirectly necessitated by the abstract syntax update.

Abstract Syntax

Element (updated)

1. identifier has been renamed to elementId.
2. humanId has been renamed to shortName.
3. name is no longer derived.

Membership (updated)

1. A new memberShortName property has been added, allowing alias short names.
2. A new memberElementId property has been added, derived as the elementId of the memberElement.
3. The ownedMemberElement and effectiveMemberName properties have been removed.

OwningMembership (new)

1. OwningMembership is a new subclass of Membership. The ownedMembers of a Namespace are related to the Namespace using OwningMembership, while alias members are related using the Membership superclass.
2. The memberElement property from Membership is redefined in OwningMembership as a composite ownedMemberElement property. Previously, a Membership owning its memberElement also had an ownedMemberElement property. Now, an OwningMembership has only the owningMemberElement, which is also its memberElement when considered as an instance of the Membership superclass.
3. memberName, memberShortName and memberElementId are redefined to ownedMemberName, ownedMemberShortName and ownedMemberElementId, respectively, and are derived as the effectiveName, shortName and elementId of the ownedMemberElement.

FeatureValue and ElementFilterMembership (updated)

1. FeatureValue and ElementFilterMembership are now subclasses of OwningMembership rather than Membership. These kinds of Membership already owned their memberElements.

   FeatureMembership (updated)

2. FeatureMembership is now a subclass of OwningMembership. Previously, it was possible (in KerML) to have a non-owning FeatureMembership. However, this is really no longer necessary, since TypeFeaturing relationships can be used to give a Feature domain Types in addition to the owningType it gets from its owningFeatureMembership (if any).

3. The memberFeature property has been removed. The ownedMemberFeature property redefines the ownedMemberElement property from OwningMembership.

4. All subclasses of FeatureMembership (EndMembership, ParameterMembership, ReturnParameterMembership, ResultExpressionMembership and various specializations in the SysML abstract syntax) already required ownership (redefining ownedMemberFeature), so no change is needed for them (except that the redundant memberParameter property is removed from ParameterMembership).

Concrete Syntax

Name resolution

The name resolution algorithm in org.omg.sysml.kerml.xtext.KerMLScope has been updated so that memberNames and memberShortNames are handled identically (except for one special case, which already existed, when the name of an ownedMemberElement is used instead of its effectiveName, to avoid circular name resolution when computing the effectiveName).

Invocation expressions

1. Named-argument notation. In an InvocationExpression using named-argument notation (such as F(x = 1, y = 2)), the argument expressions (e.g., 1 and 2) were previously related to the InvocationExpression using FeatureMemberships whose memberNames were the argument names (e.g., x and y). These memberNames were then used during subsequent semantic transformation on the InvocationExpression to match the argument expressions to parameters of the invoked function (e.g., F). However, this parsing is no longer possible, because FeatureMembership is now an OwningMembership whose ownedMemberName is derived and cannot be set during parsing.

   A new parsing was been implemented for the named-argument notation in which each argument parses as a parameter with an explicit redefinition of the named Function parameter and with the argument Expression as its FeatureValue. For example,F(x = 1, y = 2) now parses essentially just like it would if written using FeatureValues in the expr notation (calc in SysML notation), as follows:

   expr : F {
      in feature redefines x = 1;
      in feature redefines y = 2;
   }

   Additional validation checks have been added for InvocationExpressions using the named-argument notation (i.e., those for which the parameters have explicit redefinitions), validating that each argument name is a valid Function parameter name and that each Function parameter is named at most once.

2. Positional-argument notation. For consistency, the parsing has also been updated for the positional-argument notation so that the arguments are parsed as parameters with the argument expressions as FeatureValues. In this case, the redefinitions of the Function parameters are implicit, with parameters matched in positional order. Again, this is the same parsing as for an invocation written in the expr notation with implicit parameter redefinitions. For example, F(1,2) parses essentially the same as

   expr : F {
       in feature = 1;
       in feature = 2;
   }

3. Body expressions. In order to work consistently with the new parsing of InvocationExpressions, the parsing for body expressions (e.g., of the form { ... }) has also been updated. A body expression now parses to a FeatureReferenceExpression with the body of the body expression as both an ownedFeature and the referent of the FeatureRefernceExpression. The result of the FeatureReferenceExpression is thus bound to the the body Expression itself (not its result), which gives the correct value when this is further bound to a parameter with an Evaluation type (e.g., the mapper parameter for the collect Function). For example, {in x : Integer; x + 1} now maps essentially like

   expr () result : Evaluation {
       expr e {in x : Integer; x + 1}
       binding result = e;
   }

   This parsing should now also be correct for all valid uses of body expressions, whereas the previous parsing (without the wrapping FeatureReferenceExpression) was really only correct in certain special cases.

Kernel Library

1. ControlFunctions. The expr features on various Functions in the ControlFunctions package have now all been marked as in parameters, which work consistently with the new parsings for InvocationExpressions, as described above. (Previously, these features were not parameters and were handled as special cases for the invocations of these Functions.)

[himi]

I pushed some small fixes to show aliases in compartments. I noticed that it's still lacking to show aliases in titles. I will deal with it in the separate PR.

[himi]

I also changed PlantUML visualizer to use Element.getElementId() rather than generating IDs by itself.