1721 semantic domain lite

[fm-117]

Link to issue : #1721.

This PR integrates SemanticDomain objects with the exception of :

• NamespaceSymboland RootSymbolTable classes
• Resolve* methods
• RenamesSymbol and associated code have also been discarded
• Program expansion mechanism

As a consequence, some alterations had to be made. Resolution of variables is still done through SymbolTable and type linking is not performed in SemanticDomain.
Important spots for the next steps of SD integration have been marked with TODO SemanticDomain.

While working on this PR, I noticed some potential improvements :

• Pointers are considered as usage instead of proper Type (i.e. PointerType class is currently not used)
• There is no consistency on when and how to set the Owner of a symbol. This may lead to useless affectations or errors
• Some symbols have unused constructors or some constructors may be improved by requesting data at instanciation time instead of expecting the caller to set it correctly later
• Dump methods (used for text rendering) may be bugged because some do not use indentation properly

Those should be discussed all together to improve the overall quality and stability of the code.

[mayanje]

I have been assigned to this PR, but at this time this PR is not compatible with CFG/DFA because in ProgramSymbol the method ResolveReference has been removed, this method is used in CFG/DFA.
ResolveReference has been validated in CrossChecker using the definition #if DOMAIN_CHECKER.
All Tests have passed against this directive. As this PR is intended to be used for CFG/DFA ResolveReference must be included too.

I remember ResolveReference algorithm has discovered the following issue Fix global name resolution #1360

[smedilol]

@mayanje Weve discussed it many times, CFG and DFA will now use the Dictionary StorageAreaReadsSymbol and StorageAreaWritesSymbol on Node.

You can look at my private branch so see how it works:
https://github.com/osmedile/TypeCobol/blob/1260_DFA-Cobol85/TypeCobol.Analysis/Dfa/TypeCobolDataFlowGraphBuilder.cs

@osmedile Ok but your private branch is not this branch, so where is the discussion?

[mayanje]

As I answered to @osmedile his private branch is not this branch, so where is the discussion?

So I think the ResolveReference method in ProgramSymbol must be kept, and only adapted to use StorageAreaReadsSymbol instead. So that I will not have to change CFG/DFA symbol lookup mechanism.
In the current PR it seems that the StorageAreaReadsSymbol is not alimented with VariableSymbol. instances

[fm-117]

The dictionaries are populated in CrossChecker, you can see it at line 651.

[mayanje]

@fm-117 can you re add the ResolveReference method in ProgramSymbol so that it uses the StorageAreaReadsSymbol dictionary?
public Scope.MultiSymbols ResolveReference(SymbolReference symRef, bool bRecurseEnglobingPrograms)

in CFG/DFA the parameter bRecurseEnglobingPrograms) is always set to true

[fm-117]

See #1731 for rebased version.