Config parse optimization

  This patch refactorizes the config parse phase to optimize it. It speeds up the config parse, and rationalizes some operations such as the `explode` phase into method calls to ease maintenance, and give more control on the parse flow.

Changes are described below.
    
- On the fly old attribute names to new ones map (before adding object in configuration).
- Separated standard items from templates to avoid unnecessary iterations, and reduce the dependency on the `is_tpl()` method call.
- Fixed a limitation on services exclusion: when a service having dependencies was excluded, there were an error in dependencies handling. This is fixed by the explode phase refactoring.
- On the fly objects indexation during explode phase (no more call to `create_reversed_list()` is necessary) to optimize the explode phase.
- Added complex expression detection to use standard recursion for simple expressions (most of the situations) rather than complex tree parsing to optimize the explode phase.
- On the fly conflict detection and management (no more twins management nor call to `remove_twins()` is necessary).
- Adding and indexing items are now done through method calls for better control and easier update.
- On the fly service exclusion during explode phase.
- Hardened config check: declaring a service with no bound host nor hostgroup raise an error.
- Added arbiter and scheduler config dump under JSON notation on SIGUSR2.

**Caution**: The objects indexation has changed in the `Regenerator` class. This implies that objects extending it should be modified to use the `add_item()` method rather than direct objects append, and should remove their call to `create_reversed_list()`, as this method is no more defined. This is the case for the **Livesatus module that has to be updated** to work (PR will come soon).
I'd find more logical to keep focus on the `register` attribute that has a clear meaning, even for templates that do not have a `name` parameter set, such as pack services.

What's your opinion about that ?