CFG improvements

[fm-117]

This issue regroups all wanted improvements for CFG:

Features

• human-friendly graphs
  • the current representation (Normal mode) is confusing for end user especially for PERFORM statements. To avoid huge unreadable graphs, targets of performs should be represented separately. For iterative performs, the block should be splitted in two to distinguish between the perform action and the loop condition. This will also allow to represent correctly perform with test after.
  • the PERFORM block should never be represented as part of its target group block.
• Remove empty block
  • There are a lot of empty block. Especially with if/else, evaluate/when.
  • Technical note: on a previous base code of CFG it was pretty easy to reuse current block if it's empty instead of creating a new current block. Except for the current block created by StartBlockSentence method

Code and internal mechanism

• BasicBlock<N, D> and BasicBlockForNode : Merge BasicBlockForNode into BasicBlock and remove generic parameter N. The whole CFG builder is heavily tied to Node structure, thus only a Node can be used with CFG.
• Remove code duplicates (check with a tool like https://www.jetbrains.com/help/resharper/dupFinder.html)
  • At least factorize Current block creation
• Copied from 1260 cfg semantic domain lite #1735: split ControlFlowGraphBuilder into 2 classes
  • one should be responsible for the jumps between builders when entering or leaving program/function
    • would inherit from ProgramClassBuilderNodeListener
    • would override Enter/Exit and forward calls to the other class (calling EnterXXX/LeaveXXX methods with typed node)
  • the other would be responsible for the actual building of a graph for a single program/function
    • contains the EnterXXX/LeaveXXX methods
• Review code so as methods are as close as possible of the objects they relate to
  • example: GetTerminalSuccessorEdges deals more with blocks than MultiBranchContext
• Discuss the option of building a joining End node in graphs (role of the End flag, see 1260 cfg semantic domain lite #1735 (comment))
• The concept of Analyzer may evolve because of the introduction of new kinds of analyzers for quality rules. Besides, CFG builder is a special case of SyntaxDrivenAnalyzer because it is an internal tool later used for other analysis. Moving the CFG building after the CrossCheck would solve this problem.
• Role of the BasicBlockForNodeGroup class: if we build separate graphs for PERFORMs, the group as a block may not be useful. Also in Extended mode, the group is not required as the graph is built as a single chain. To discuss. Currently this class introduces many type checks and creates complexity in the code.