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.
Code did not even compile when I downloaded it and started working, and tests did not pass after I changed things to compile. Due to the lack of time I had to skip checking why unit tests do not pass, also as there is no explanation on what do the tests actually check. Especially since it takes a lot of time to understand what is there, as many things seem overly engineered with no obvious explanation of why.