Some suggestions for the KnowledgeManagersView class.
@rima-alali, @keznikl, @mkit
Extensions of the SampleRuntimeModel class to create also an ensemble.
Changes in the meta-model:
- remove ComponentInstance.id
- change OtherKnowledgeManagersAccess to KnowledgeManagersView
- have separate scheduling specifications for the member and the
coordinator (the main reason is to have separate triggers)

Further changes include separation of the the EnsembleTask into two (one
for a coordinator, another for all members). This is because they have
different scheduling. They will share a lot of implementation via some
abstract predecessor (the class for the predecessor is not in place
yet).
EnsembleMemberTask renamed EnsembleMembersTask to signify that the task
actually handles multiple instances of the member role in ensembles of
the same ensemble definition.
Last change - renaming of the EnsembleMemberTask to plural reverted.
added isActive flag to the Process class in the meta-model
The split of coordinator vs. member scheduling of an ensemble reverted.
It didn't really solve the problem I had in mind (i.e. that knowledge
paths of triggers have to be striped of member/coord prefix) and by
itself, it was an overkill.

There are some more architectural suggestions in the comments.
Essentially it seems that it would make a lot of sense to have separate
trigger listeners:
KnowledgeManager: triggered(Trigger)
KnowledgeManagersView: triggered(ReadOnlyKnowledgeManager, Trigger)
Task: triggered(Task)
Updated the FIXMEs that I've inserted in the code so that they identify
me as their author. Now, it should be clear who is to be consulted if
any of the FIXMEs is not clear.
Merge pull request #80 from d3scomp/newgen-bures

Changes in the meta-model + separation of the EnsembleTask to two tasks (one for coordinator and another for members)