Don't create reply message for mapped operations with message views

[Matthias Schoettle]

When defining the behaviour for startObserving in Observer and calling addToMyObserver a reply message is created. However, the operation is mapped (by reusing Association to an operation of Data, which already has a message view.

Instead, the check whether a message view exists should include a check of mapped operations. At the same time, this would allow to restrict creating a message view for those operations as well.

[Matthias Schoettle]

The same should apply to non-mapped operations coming from an extended aspect (see #396).

[Matthias Schoettle]

References #390: Improves check of whether a message view is defined for an operation.

Adds a check to ensure that a message view is considered to be defined if an operation is mapped to an operation that is not partial. I.e., the operation is just renamed and the message view is considered to be defined in the other model.

→ <<cset 89ea9ae673e1>>

[Matthias Schoettle]

References #390: Ensures that user is warned in case message view is defined but not located in current aspect.

→ <<cset ad6b0fdec95d>>

[Matthias Schoettle]

References #390, #425: Adds test cases to determine whether reply was created or not.

→ <<cset ab933d4e4d15>>

[Matthias Schoettle]

References #390, #425: Fixes CreationTestHelper when checking arguments of reply messages.

→ <<cset 66de295b7482>>

[Matthias Schoettle]

Resolves #390: Ensures that no reply message is created for operations in other models.

The same applies to the view, in order to prevent that no nested behaviour can be defined.

→ <<cset 3bfa7e62e8a4>>