Better split the studio into independent components + applying eclipse versionning scheme

## Observations

Currently, the GEMOC Studio is conceptually split in several components, as shown approximately by this diagram from the documentation :


However, several observations can be made:
- Each component does not have its own lifecycle, and follows the version numbers and release cycle of the complete studio, regardless of the amount of changes in the component (eg. a new version of the framework is officialy released at each new version of the studio, even if it does not change). This means that if any external person depends on one specific component of the studio, and that this component changes its version number despite any real code change, this can lead to confusion.
- Each component does not have its own git repository, which means the separation we have between components is not necessarily clear (this is not a big problem per se, but can have an impact on other points)
- The current split can be discussed on several points, such as:
- The "framework" part not only contains all mandatory generic extensible components of the studio, but also one optional concrete engine (the K3/Java one) and a few optional concrete addons (notably the debugger). Splitting the mandatory generic extensible part (ie. the framework) from the specific optional extensions made using this framework (eg. the Java engine) into separate components could clarify for contributors what is *mandatory and extensible* from the *optional extensions* we officialy provide
- The "tracing" part contains the trace metamodel - which can be considered as part of the mandatory API of the framework - from tools to build tracers and traces - which are optional when executing models. Again, splitting mandatory from optional parts into well identified separate components could help.

In addition, we discovered that the Eclipse foundation has precise rules for **version numbers** of software parts: https://wiki.eclipse.org/Version_Numbering , which can be summarized as:
> Reminder: In Eclipse, version numbers are composed of four (4) segments: 3 integers and a string respectively named **major.minor.service.qualifier**.
>
> Each segment captures a different intent:
>
> - the major segment indicates breakage in the API
> - the minor segment indicates "externally visible" changes
> - the service segment indicates bug fixes and the change of development stream (the semantics attached to development stream is new to this proposal, see below)
> - the qualifier segment indicates a particular build

If we consider the "API" to be "everything that is `public`", this means that with our current process, almost each new version of the GEMOC Studio should increase the "major" segment (eg. 2.0, 3.0, 4.0, etc.), since it's unlikely that zero `public` member changes between two releases . We probably would prefer to keep the major segment for big feature changes, instead.

## Proposal

Based on all observations above, I would propose:

1. Separate the version number of the GEMOC studio (ie. the end-user graphical IDE), from the version number of the GEMOC libraries (eg. the execution framework). We could for instance have a GEMOC Studio v12 contaning an execution framework 2.5.3 and a Java engine 1.5.2. This would enable us:
1. to increment the version number of the studio without incrementing the version number of a component that did not change since the last version. Someone depending on the framework would not need to update its code/manifests in such cases, which is rather nice.
2. to use the strict eclipse version numbering *major.minor.service.qualifier* for the librairies, while keeping a more flexible numbering for the Studio itself (it is usually admitted hat the scheme *major.minor.service.qualifier* does not make sense for an end-user application, so we could consider that "major" means "lots of important features")
2. Better conceptually separate components, eg. separate the framework from the java engine (this would need discussions)
3. Better technically separate components, each with one git repository, its own life cycle, its own update site and its own sequence of git releases. This would greatly help implementing the first point.
4. Ask for a an eclipse github organization dedicated to GEMOC. This would greatly help implementing the previous point.