This PR implements the resolution to the following issue from SysML v2 FTF2 Ballot 5:

• SYSML2_-159 Textual notation for send actions is too limited

(This resolution should have been implemented in the 2024-12 release, but it was missed.)

The update in this PR improves the expressiveness of send action usage syntax, while still maintaining the parsability of send action usages used as entry, do or exit actions, or used as transition effect actions. In particular, send action usage notation of the following form is allowed, in which all parameters are bound in the send action usage body:

send{
    inpayload =payloadExpression;
    insender =senderExpression;
    inreceiver =receiverExperssion;
}

as well as the following mixed forms

sendpayloadExpression {
    insender =senderExpression;
    inreceiver =receiverExperssion;
}

and

sendpayloadExpressionviasenderExpression{
    inreceiver =receiverExperssion;
}

Further, instead of using feature values, values can also be provided for the nested parameters by using either flows or binding connections outside the send action usage. In addition, in the form

actionactionNamesend viapayloadExpressiontoreceiverExpression;

the payload parameter is also implicitly redefined, but it can still be referred to by name (e.g., actionName.payload), for use as the target of a flow or binding connection.

There is also a similar update to the syntax for accept action usages. The current syntax is

accepttriggerDeclarationviareceiverExpression;

It is now also possible to redefine the receiver parameter (but not the triggerDeclaration, which declares an output parameter) in the body of the accept action usage, so it can be given a value using an explicit binding or flow. The proposed notation has the form:

accepttriggerDeclaration{
    inreceiver =receiverExpression;
}