ST6RI-950 UsageImpl silently changes isComposite=false to true after an XMI round-trip

[adaussy]

This PR fixes a bug that caused the isComposite property of a Usage to always be true when reading from XMI, even if it was false in the XMI. The fix presumes the changes already made in PR #793.

Background

UsageImpl initialized the inherited Feature::isComposite property to true directly in its constructor:

/**
 * <!-- begin-user-doc -->
 * <!-- end-user-doc -->
 * @generated NOT
 */
protected UsageImpl() {
    super();
    isComposite = true;
}

This conflicts with the declared Ecore default of the inherited property:

<eStructuralFeatures
    xsi:type="ecore:EAttribute"
    name="isComposite"
    lowerBound="1"
    eType="ecore:EDataType  "
    defaultValueLiteral="false">

As a result, an explicit isComposite=false value was silently changed to true after saving and reloading the model.

This is not only a difference between two default-value conventions. It violates the fundamental persistence invariant:

load(save(model)) 

must preserve the semantic state of model.

Note that this was not a problem for Xtext parsing, because isComposite could be set during parsing after a Usage element was created, if a ref keyword is found or during post-processing. The intent was that the Usage element would default to isComposite = true in the abstract syntax otherwise, but that the XMI default isComposite would still be false, as for KerML. As outlined above, however, this does no work for an XMI roundtrip.

Changes

The following changes were made following the changes made in PR #793.

1. In org.omg.sysml.xtext.postprocessor.UsageParserPostProcessor, use Xtext node information to preserve explicit isComposite and isReference assignments while restoring implicit parser defaults during post-processing.
2. In the abstract suntax, remove constructor-specific isComposite initialization, restoring standard EMF creation and XMI deserialization aligned with the Ecore default.