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.
Yes. Basically, we need any metric as anyone can use any metric name. If there is some different metric, we need to be able to 1: collect it, 2: define requirements on it, 3:create  using composition rules though COMOT API and then define requirements on it.

Supporting just a fixed static set of metrics greatly reduces the applicability of our approach. We should not assume we can have everything completely defined in terms of metrics at COMOT design time.