To pyg5k resa

This patch is the foundation of the migration.

It only adresses the most common use case:

- As a user I want some machines, possibly on different sites
- As a user I want to destroy all the resources corresponding to my experiment

We only consider machines here: networks (kavlan and subnet) would need to be
taken care of in another patch.

Note that currently execo_g5k.api_utils and python-grid5000 co-exist.

What's inside:

1. The function `enos_g5k.utils.grid_get_or_create_job` has been revisited, and
now exclusivemy uses python-grid5000 [new]

    1.1 The name of the experiment (specify in the top level of the enoslib
    configuration) is critical. One **must** have only one experiment with the same
    name running [same as before]

    1.2 An experiment is given a name (see above) and all the jobs with that name on
    the testbed is reloaded. If no job is found we create the new ones [same as before]

    1.3 An experiment can be composed of several jobs (one per site where resources
    are claimed) [new -- before oargrid was taking care of that]

    1.4 A naive job synchronisation is introduced to prevent job start to drift too
    much between sites [new -- before oargrid was taking of that]

2. enos_g5k.utils.grid_destroy_from_name has been revisited. This destroys all
   the jobs on all site with the name [new -- before oargrid was taking care of
   that]

3. The client is loaded in `enos_g5k.provider` and pass to the underlying driver.
   One **must** have a python-grid5000 configuration file ready
   ($HOME/.python-grid5000.yaml)