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.
is there a particular reason for a `List<ServiceUnit>` instead of `Set<ServiceUnit>`? A set has the advantage that it can only contain distinct elements