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.
I guess we need those more "generic" metrics for the composed metrics used by MELA so that we can define them on the COMOT model using the API? Otherwise, I don't see any benefit from this since you loose type safety.