Comot orchestrator

We have modified a bit things and developed a new module for having a working version of COMOT for summer soc, in which we describe the DaaS with the COMOT flow API, COMOT calls SALSA for deployment, queries SALSA for service information, transforms that information, and sends it to rSYBL.  

Modifications have also been made in the "common" model. Among others
  - renamed names like *Node to *Unit.
  - modified Metric pojo to support any metric name and unit, instead of a staticly defined enum. 
  - added ServiceTopology concept and modified transformation to TOSCA such that SALSA receives tosca WITHOUT service topologies (all units are in one TOSCA topology), but rSYBL receives service information according to the Service-ServiceTopology-ServiceUnit model
  - added ElasticityCapabilities on AbstractServiceDescriptionEntity, as a base on which we will define the capability for each Unit or topology. Currently ScaleIN/Out capabilities are automatically added if a scale in/out 

Client modification: 
   - added client to connect to rSYBL
   -  updated SALSA client to also query for service information

Added a comot-orchestrator module, which should be the base for creating a real COMOT Orchestrator which communicates to and orchestrates between SALSA, MELA and rSYBL. SALSA should not orchestrate everything.
There is another important issue here. From what I saw, you support only binary relationships, such as Rule A AND/OR Rule B, not additional compositions, such as of A and B or C,     or A and (B or C).  We need to be able to express from simple to complex constraints/strategies.
Not sure if having methods for "and, or..." is good or bad, but yes, their impact is minimal on readability.