Refactoring the dataflow of CreateFspec

[stefjoosten]

@hanjoosten and @stefjoosten ran into the need to refactor the function createMulti :: Options -> IO(Guarded MultiFSpecs) from module CreateFspec. Neither of us could solve issue #967 because function createMulti is too complex to analyze.

Version of ampersand that was used

Ampersand-v3.17.0 [data-analysis:e4d946007*]

Problem

It was too complicated to analyze the code of the mentioned function. Here is part of the analysis: So I called Han for explanation

Analysis

We decided to rethink the workflow because of the different command-line options and the various artifacts justify thinking before doing. We also decided we don't have the answers yet, so opening a dialogue seems like a good idea. Here is my first shot at the internal data flow of the compiler (Han, now it's your turn):

Remarks:

1. The atlas app is an application with no interfaces. Therefore, it does not need SystemContext.adl.
2. A new idea is to implement Atlas as a separate application. That separates out one concern in an apparently clean way.
3. The layer separation P-structure/A-structure/F-structure is interrupted by grind, which needs a typed specification (at least an A-structure) for grinding correctly. The resulting P_structure must be merged with a FormalAmpersand context, so the result must be type-checked again. (Remark: is this really true? Could that be avoided somehow?)