Replace the downstream API handling by the new messaging layer. Not that
we don't have a clean way to deal with dynamic concurrency control using
this API, so we disable the handling of it for now.

Added profiling parameter to manifest file that can be used to specify
if power profile is required for a container/application. Also, changed
namedtuple "Container" key from "powerpolicy" to "power" and made
changes to reflect this

See Issue #12

Made changes in NRM to respond to phase_context event from [previously
called power_policy event (874a6a4d)] from the application. The NRM can now
store the informaton received on the event and call DDCM power policy through
interfaces developed (Issue #11) in the control loop

See Issue #10

This patch introduce one more level of abstraction to the controller:
an actuator. Actuators will act as the middleman between specific
managers and the controller, while providing enough info to implement
actual models on top.

For now, we only have the application threads actuator.

This patch moves the tracking of applications clients of the downstream
API into a ApplicationManager, that is able to track progress and thread
management.

This change is necessary in the long term to build a comprehensive
downstream API and centralize the management of application tracking.

Note that this tracking is currently independent of the container and
pid tracking, and that might be a problem in the long term.