[DIC] [RFC] Plain array configs

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| License       | MIT
| Doc PR        | n/a

In this PR I want to discuss the following config format:
```php
<?php

use Symfony\Component\DependencyInjection\ContainerInterface;

return [
    'parameters' => [
        'foo' => 42,
        'bar' => 'bar'
    ],

    'services' => [
       	// à la Pimple, by default
        'foo' => [
            'class' => FooBarBaz::class,
            'factory_method' => function (ContainerInterface $container) {
                return new FooBarBaz($container->getParameter('foo'));
            }
        ],

       	// with arguments
        'bar' => [
            'class' => FooBarBaz::class,
            'factory_method' => function ($bar) {
                return new FooBarBaz($bar);
            },
            'arguments' => ['%bar%']
        ]
    ]
];
```

There are some reasons to use plain arrays instead of YAML/XML in some cases:

1. [Short array syntax](http://php.net/manual/en/language.types.array.php#example-96) was introduced years ago and it minimises difference between YAML and plain array in readability.
2. [Class name resolution](http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class) allows IDE to find class usages, apply renaming, go to class by click, etc.
2. Expression language is nice, but it looks awkward in YAML/XML configs (well, at least for me). My point is to use closures for inline logic instead.

The main disadvantage of plain array against YAML/XML is lack of sandboxing. It can lead abusing of code in configs. But on other hand pure PHP config format has the same problem.

Unfortunately, I see some problems in order to create real PR:
1. My PR depends on [Super Closure](https://github.com/jeremeamia/super_closure) library for dumping closure's code, but I'm not sure if you accept it. By the way, only [context free](https://github.com/jeremeamia/super_closure/pull/20) closures can be dumped, it's some sort of restriction.
2. `PhpFileLoader` already holds *.php extension, so order of loaders matters.

What do you think?
It must be possible to share some code with the YamlFileParser.