Allow ports in subprogram types

[stevevestal]

The only kind of port declaration currently allowed in a subprogram type is an out event data port. This asymmetry seems confusing and unnecessarily restrictive. Source code for a subprogram (or subprogram group) may contain any read/receive or write/send service calls that could appear in source code associated with a thread. Subprogram execution is just a part of thread execution.

The ability to do this is useful for patterns that insert message transformations, e.g., in a transformation subprogram that is a "requires subprogram access" feature of a thread, or a pattern that injects a wrapper into a process to align otherwise inconsistent port types with thread groups (such as FACE UoPs hosted in a process).

[reteprelief]

The reason for the restriction was to use ports for modeling exceptions, which typically are only outgoing. If we allow ports in general then they can play the role of parameter and we would not need parameter as a construct.

[stevevestal]

Ah, yes, I see in the standard that parameters do double-duty as both message ports/queues/buffers and call parameter passing for subprogram objects.

[stevevestal]

Or perhaps a better interpretation is that a port-to-port connection has a subtly different implementation semantics/mechanism than a port-to-parameter connection.

[stevevestal]

Closing this, it can be covered by a suitable semantic interpretation of port to property connections.