Wishlist for a "metaprogramming approach" extension point

While GEMOC Studio only supports one single language for defining an abstract syntax (Ecore), it aims at supporting several metaprogramming approaches for defining the semantics (eg. K3, K3+CSSL, xMOF, etc).

Recently, the keyword `metaprog` has been added to the new `.dsl` language, to be able to declare how the semantics of a given DSL have been defined (eg. `"k3"`, `"k3+ccsl"`, `"xmof"`, etc.).

Complementarily, it would be awesome to have an Eclipse *metaprog* extension point to make GEMOC trully extensible regarding metaprogramming approaches. A metaprog extension would be loaded based on the `metaprog` declared at the beginning of a `.dsl` file (eg. the K3 metaprog extension would be loaded if the `.dsl` file starts with `metaprog "k3"`).

Here is a wishlist of what such an extension could/should provide for a given metaprogramming approach:
- An execution engine, obviously
- If we write an extensible unique Launch Configuration UI, an (optional) customization of this UI (eg. with xMOF semantics, to pass arguments to the xMOF virtual machine)
- An abstract and generic representation of the semantics of the DSL, which could be used as a pivot for many generative approaches (eg. event/trace metamodels generation). This representation could include:
- what are is the definition of the model state (aka runtime/dynamic data)
- what are the execution rules and the relationships between the rules
- A validator for the `.dsl` file, which would almost act as an extension to the syntax of the `.dsl` language (eg. the Kermeta metaprog could trigger a warning/error if no aspect is declared in the `.dsl` file, while the xMOF validator could do the same if no xmof file is declared)
- A rule executor, to arbitrarily execute one rule of the semantics (maybe this can/should be done by the engine directly, since a rule should always be executed in a given context, and this context is contained in the engine)
- https://github.com/eclipse/gemoc-studio/issues/41 A generic interface to access the model state (ie the dynamic/runtime data) of the model, which would maybe enable an easier support of metaprog approaches where the state is not stored explicitly as an EMF model or as part of an EMF model.

... and probably more