Introduction of a central agent for archipel

Archipel is a mostly decentralized system but some common features of orchestrators require centralized tracking of the vms and hypervisors, namely high availability, billing and more. This introduces a new module, archipel_central_agent, whose role is to write to central sqlite3 database. Every hypervisor can read the database though.

The schema of this central db consists of an "hypervisor" table and a "vm" table. It replaces the previously existing vmparking database. Most of the vm parking functionality is unchanged though.

Every hypervisors subscribes to the central agent pubsub whose purpose is to advertise periodically the central agent jid.

Another feature is "ping" where the central agent checks that hypervisors are alive. In the event that a hypervisor becomes unavailable, its vms can be started on another one (there is no such capability on ArchipelClient for the moment, it has to be done via custom acps)

An exit proc is added where the function archipel_exit_proc is executed when the agent is interrupted. This function removes the hypervisor from the central db before archipel stops.

There are 2 modes of operation : "standalone" where an archipel entity acts as central agent only (making use of the new file archipelCentralAgent.py in archipel-agent folder) or "distributed" where a random hypervisor acts as central agent.

It has been tested only on a simulated environment using nested virtualization. The test code is added in a new folder ArchipelTest. It is a full integrated test environment for archipel agent. For now it covers only the central agent functionality.

Testing is required on a real hypervisor environment. Some UI work may also be required. Documentation will come shortly.