Provide a DSL behavior aware error reporting service in GEMOC

One of the activities a language designer has to do is to handle how a model execution should behave when the provided model is incorrect.

One way is to statically check it (using contraints), even if this is a good practice, this not always possible (for example with external event which may produce a stop of the execution), or it might be simpler to crash at runtime rather than try to check all possibilities, or the designed dsl is dynamically typed (thus the early stage check is just impossible)

The second way is to stop the model execution and report the error to the user (ie. the model designer).
One simple implementation is to use the underlying implementation language exception mecanism. Actually, this is not the expected level of details from the model designer point of view. since the exception will have in its stacktrace elements not related to the `@step` (for example intermediate call to methods related to implementation details that are useful only for the language designer).

Currently ALE has no Exception concept (https://github.com/gemoc/ale-lang/issues/37), but more than such concept what I really expect is a kind of service that would take into account GEMOC concepts to provide an error to the model designer.
It should show a report of the status of the model when it crashed with:
- a user readable message
- a stacktrace that shows only declared Steps (ie. other methods call are ignored or hidden), this trace should should method call AND involved model elements
- a snapshot of the runtime data
- information about the engine (ie. in a concurrent engine, some specific data about other step might be interresting too)

The Ui would then present this according to the run mode. In debug, I expect a graphical presentation of most of this. In test/scenario run mode, I expect a fully textual output.
Additionaly, in debug mode, may be we can have a language designer/model designer switch allowing to show hide intermediate "non step" calls.

Most of the required data are actually available in the engine and the trace addon, so this service should probably be realted to them.