Better diagnostic of desynchronization of generated files

The flag of desynchronization of generated elements does not indicate how much the generated code is impacted. A change in a design file can lead to a very limited change in the generated code, for example purely cosmetic change like indentation, comment, or sometimes no change at all. In the other hand, a change in a design file can sometimes lead to a large reorganization of the source code. The flag of desynchronization is not able to make the difference between these two extreme cases.

We think the tool should provide a detailed analysis of the change in a generated code after a change in the design. We suggest to have a new analysis function that can be run either on a single generated file or on a list of generated files selected in the Generation Manager, or on all the generated files in the workspace (in this last case, should be executed during the night or week-end).

When launched on a single generated file, this analysis will launch a generation in memory and then, will open a comparison editor to show the differences between the old and the new generated code. This is a generalization of the preview function currently available when a new macrostructure is called in a program. In the comparison editor, it will be possible for the user to take into account the new generated code or to keep the old generated code and keep the desynchronized state. If the user decides to keep the old generated code for now, new indicators will be set in the Generation Manager, the same indicators that will be explained below in case of multiple generated files.

When the analysis function is called on a list of generated files, it were not practical to open several comparison editors. Then, we propose a different behavior in this case : the result of the analysis will be to set new indicators associated to each generated artifact, shown in new columns in the the Generation Manager.

The suggested new columns in the Generation Manager are :
- A flag Yes/No telling if the change in the generated code is only a cosmetic change (indentation, comment, margins, ...).
- The total number of lines that have been changed in the generated file and the number of added, removed and modified lines.
- The number of reconciliation warnings that will be put on the code after regeneration.

Then, these new columns should be sortable and also the user should be able to filter the Generation Manager according to these columns. Also, the new columns should be exportable in the CSV export.

These new indicators can allow the users to have a much better understanding fo the real impact of desynchronizations in the workspace.