[UML_VIEW] Add possibility to specify values for absent parts of UML sequence

[svlad-90]

It might happen, that formatting of existing messages in the project does not fit constraint to have all mandatory UML groups. Thus the creation of a sequence diagram is not possible. Still, the client might understand that specific formatting of the message is representing communication with a specific interface and method, and wants to provide this information as part of the regex. We should allow the client to do this.

---

Let's consider the following example:

2206 2020/08/06 15:27:04.204000 276163.1118 ECU1 SYS JOUR 2020/08/06 15:27:03.556033 cat[49294]: Informational: CAlice: sentName(name: "Alice") 2207 2020/08/06 15:27:04.703000 276163.5468 ECU1 SYS JOUR 2020/08/06 15:27:03.991085 cat[49299]: Informational: CAlice: response(success: 1)

What would I expect to do with the above messages?

• Specify Alex as a CLIENT, despite that string has CAlice
• Specify Bob as a SERVICE, despite it is not presented in the message
• Specify sayMyName as a method, despite it is not presented in the message
• Specify request, response, event, despite they are not presented in the message directly

I want to use the following regex in order to achieve the above mentioned points: ^(SYS).?: Informational: (?CAlice):.?(?(?(?sentName)|(?response))).*((?[\w]+))

New parts of behavior:

• UCL_Alex will replace CAlice to Alex in the diagram content ( not supported yet )
• US_Bob will add Bob service, despite, that it is not presented in the message ( not supported yet )
• UM_sayMyName will add sayMyName method, despite that it is not presented in the message ( not supported yet )
• URT & URP are stick to the parts of the message, which only indirectly show whether it is request or response ( supported already )

If supported, above will allow creating sequence diagrams even from non-perfectly formatted messages, expanding the number of covered use-cases.

P.S. Together with that, it would be good to remove the 32 characters limitation on size of the regex group names. It should be possible to do that via internal mapping of provided group names to some shorter identifiers, e.g. counter-based ones - 1, 2, 3, 4, etc. Short identifiers would be actually used within the regex, while long names would be still known to the plugin's implementation.

[svlad-90]

It was decided, that we will deal with removal of 32 chars regex group name limitation using a separate task: https://github.com/svlad-90/DLT-Message-Analyzer/issues/87