[WIP] [ContainerBuilder] Create your services with lazy loading


| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Currently, we can define a service as "lazy". But this behaviour is limited. If we want to use lazy loading with getter/setter inside a big controller (or a big service), there is no real solution. This new feature will bring solution to have lazy loading during your services creation.

+ What is a lazy call?

A lazy call config is exactly like a "call" method config, but the method is called lazily. Called on demand, when you need to use your dependence.

+ How it works?

You can define a lazy call like a simple call :
```php
service1:
            lazy_calls:
                        - [ setBar, [ foo ] ]
```
In this case, when you will call `getBar` of your service `service1`, the `setBar` method will be called by the proxy to init your service/controller. Because if your don't define any triggering condition, the method will be base on getter/setter method.

Otherwise, you can define what will be your trigger :

```php
service1:
            lazy_calls:
                        - [ setBar, [ foo ], property : foo ]
                        - [ setBar, [ foo ], method : foo ]
```
With the first example, when you will use the `foo` property inside your service `service1`, the `setBar` method will be called by the proxy to init your service/controller. 
With the second one, when you will use the `foo` method of your service `service1`, the `setBar` method will be called by the proxy to init your service/controller. 

If you don't use the `ProxyManager` project, the `RealServiceInstanciator' will use lazy calls like classic call. Otherwise, your dependence will be injected when you will use the related property/related method you have defined to trigger the initialization.

+ Why do I need this?

Some of your controllers or services will have a lot of dependence but they won't be use all the services injected. If the injection of the Container can be a solution, it's a solution hard to test. The lazy loading will bring more flexibility to remove the dependence of the ContainerBuilder from your code.
Because you will get services on-demand, this lazy loading can prevent circular dependence or memory consumption during your services building.

+ What's the remaining work?

I need to have the feedback of @stof and @Ocramius to know if this feature can be integrated in the DependencyInjection component. Then, if yes, there will some work to add : synchronize feature and tests to add, documentation? ... that's a first draft for now.
for instance, if your get the service instance in a compiler pass (which is a bad practice but I know that it does not prevent it to be done), you potentially won't be able to dump your container anymore because the call will contain a closure