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'm referring to the code above : else item.configuration_warning.append. 

This else is true when existing_prio == item_prio. My question was : are you sure this value will differ between objects? Because I experienced the opposite and could not find a place where this attribute is incremented (item.definition_order)