Fix for iterative and recursive PERFORMs

[fm-117]

Based on 62a1c96 and adapted to this branch using SemanticDomain Lite.

[fm-117]

A bug has been identified in the clonedPerforms handling. This sample produces 2 recursivity diagnostics although the code isn't recursive.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DVZZMFT1.
       DATA DIVISION.
       PROCEDURE DIVISION.
       main.
           PERFORM a
           GOBACK
           .
       a.
           PERFORM b
           PERFORM c
           .
       b.
           PERFORM d
           .
       c.
           PERFORM d
           .
       d.
           DISPLAY "end !"
           .
       END PROGRAM DVZZMFT1.

[mayanje]

Thus to validate this PR, I prefer wating for the last issue to be fixed, using the fix provided in branch:
https://github.com/TypeCobolTeam/TypeCobol/tree/1260_TypeCobolCFG

[fm-117]

Now includes latest fixes from 1260_TypeCobolCFG

• avoid multiple outgoing edges
• fix recursion detection

[smedilol]

Same problem here, the block29 should point to block30

[rooksdo]

B-LOOP block should also be delimited by a blue line as in PerformProcedure0. Actually, PerformProcedure0 seems to avoid the bug detected by @smedilol .

[fm-117]

This is not bug but a feature 😆 ! The difference between PerformProcedure0 and PerformProcedure2 is that the PERFORM B-LOOP instruction uses a TEST AFTER clause. This PR introduces specifically some changes to represent performs having a TEST AFTER clause.

[rooksdo]

B-LOOP block should also be delimited by a blue line as in PerformProcedure0. Actually, PerformProcedure0 seems to avoid the bug detected by @smedilol .

[rooksdo]

Following the same logic as @smedilol's remarks, we should have block11->block12. So, the instruction TEST AFTER should not affect the end graph.

[fm-117]

About the last two commits :

• in GEFDOT, an empty subgraph leads to a rectangle drawn around all blocks of the graph (whereas in Graphviz, nothing is drawn for empty subgraphs). So from now on, we check the content of a subgraph before writing it to the output file.
• in DOT (in general), if an edge belongs to a subgraph, then its target block will be included into this subgraph. This would result in PERFORM blocks being forcingly relocated into subgraphs. The fix here consists in writing edges only at the root level. As a consequence, subgraphs no longer have edges, only blocks.

This is not perfect though, there is still a bug with those blue rectangles: for example in PerformProcIterativeAfterRecursive2.dot, no rectangle is drawn at all because no subgraph is generated. This is related to the current handling of AFTER clauses. So I think it is better to leave it as it is and change that with #1783 altogether.

[rooksdo]

Ok with @fm-117, the known limitations of graphic representation should be addressed in #1783. This PR is ok as it is.