ST6RI-851 Remove automatic insertion of explicit subject and objective features

[seidewitz]

Previously, if a requirement definition/usage or case definition/usage was parsed without an owned subject and/or objective, then a subject or objective element was physically inserted into the parse tree by the relevant adapter. This resolved difficulties with managing required redefinitions of subject and objective features from general types of a requirement or case, but it is not conformant with the SysML Specification. This PR removes these automatic insertions.

Key Changes

1. CaseDefinitionAdapter, CaseUsageAdapter, RequirementDefinitionAdapter, RequirementUsageAdapter – Removed the overrides of addAdditionalMembers.
2. RequirementUsageAdapter – Updated computation of the implicit redefinitions of an objective requirement to handle redefining subjects and objectives that are not directly owned by general types. (This is already handle for a subject parameter by the general rules for implied redefinitions of a parameter.)
3. SysMLValidator – Updated validation checks on subject and objective features to handle if they are inherited.

Other Fixes

1. Type_directionOf_InvocationDelegate – Revised the implementation of the operation Type::directionOf to handle implied specializations.
2. Type_input_SettingDelegate, Type_output_SettingDelegate – Corrected the computation of the derived properties Type::input and Type::output.
3. Systems Model Library – Changed the direction of StateTransitionAction::payload from out to inout.

Backwards Incompatibilities

While this makes the Pilot Implementation more conformant with the SysML specification, it also results in some backward incompatibility with past Pilot Implementation behavior. In particular, the previous insertion of subjects meant that the validation checks for the subject being the first parameter were satisfied even if the subject was not declared explicitly and there were additional parameters. This is no longer necessarily the case.

For example, the following requirement definition would previously have not produced an error, but now results in a "Subject must be first parameter" validation error.

requirement def R {
    in x;
}

In particular, stakeholders and actors are kinds of parameters, so a subject must always be explicitly declared if stakeholders and/or actors are also declared.

concern c {
    subject; // Required to avoid error.
    stakeholder s;
}
use case uc {
    subject; // Required to avoid error.
    actor a;
}

Note that this is the case even when specializing a supertype with an inheritable subject:

use case uc1 {
    subject subj;
}
use case uc2 :> uc1 {
    subject subj; // Implied redefinition of uc1::subj.
    actor a;
}
use case uc3 :> uc, uc1 {
    subject; // Required to avoid "Only one subject is allowed" error.
}