Unified Melange-less approach to represent and access dynamic data (ie. model state)

We (Benoit and me) discussed how to unify in the GEMOC Studio how dynamic data are defined in the language, and how they are manipulated at runtime for a given executed model.

Each metalanguage has its own way to define dynamic data (eg. aspect weaving, inheritance, separate metamodel, etc.), and its own way to represent dynamic data at runtime (one unique extended EMF model with both static and dynamic data, one static EMF model + one dynamic EMF model, one static model + non-EMF dynamic data, etc.).

The main problem is that we want to manipulate dynamic data (both its definition at design time, and the actual data at runtime) in a generic way to define generic tools, and in a specific way to define domain-specific tools.

At the moment, domain-specific manipulation is obtained through Melange (that generates the extended ecore at design time + convert into an extended model with a MelangeResource at runtime). But (1) this means extending Melange for each metalanguage (eg. the xmof keyword), and (2) Melange will soon be out of GEMOC.

Therefore, instead, we could aim for the following services provided by the metalanguage GEMOC integration:
- for language design time, one model transformation that takes (1) the abstract syntax, (2) a metalanguage-specific specification of the dynamic data structure (eg. K3 aspects), and produces a new ecore metamodel with dynamic data weaved in the AS
- this part could actually probably be avoided if we have a unified abstract way to represent the operational semantics, for all metalanguages (see https://github.com/eclipse/gemoc-studio/issues/37 )
- one unique generic metamodel to represent dynamic data generically
- for runtime, one inplace model transformation that takes the metalanguage-specific representation of the dynamic data, and updates a generic model containing all the dynamic data (eg. to have a nice generic API to access the state)
- for runtime, one inplace model transformation that takes the metalanguage-specific representation of the dynamic data, and updates the extended model conforming to the extended metamodel (eg. to have a nice specific API to access the state)
- this part could actually probably be implemented generically, based on the implementation of the previous point

One problem would remain: while it's probably do-able to provide a one way propagation of the model state to the GEMOC representations of the model state (specific and generic), but a bidirectionnal relationship would be quite annoying (eg. a tool that arbitrarily changes the dynamic data, without going through the interpreter of the language)