feature #3894 Rewrote Extension & Configuration docs (WouterJ)

This PR was merged into the 2.3 branch.

Discussion
----------

Rewrote Extension & Configuration docs

The "How to expose semantic configuration for a bundle" article always was a bit of a mess. It tried to explain how to use Extension classes to load service definitions and how to provide configuration options for a bundle. At the same time it showed 2 ways to achieve this goal: a simple way and the official way. This resulted in an article that wasn't easy to follow and did not really learn anything about Extensions and Configurations.

So I decided to rewrite the complete article into 2 seperate articles: One about the Extension and one about the Configuration.

While I was doing that, I discovered it was time that we rewrote this thing. Most of the article was written in Feb 2011 and was outdated now.

I've also added a section about XML configuration.

This is a first sketch, I haven't checked my english/grammar/typos, but it's ready to catch the first comments!

| Q   | A
| --- | ---
| Doc fix? | yes
| New docs? | yes
| Applies to | 2.3+
| Fixed tickets | -

Side-note: I have discussed with myself to move the article to the components docs, because most of it doesn't rely on the Symfony framework. However, since the conventions do, I decided to keep it in the cookbook to make it easier to follow.

Commits
-------

c9fe05b Rewrote Extension & Configuration docs

Author: weaverryan

components/config/definition.rst

@@ -391,6 +391,8 @@ with ``append()``::
 This is also useful to help you avoid repeating yourself if you have sections
 of the config that are repeated in different places.
 
+.. _component-config-normalization:
+
 Normalization
 -------------
 
@@ -445,6 +447,8 @@ a second argument::
         ->fixXmlConfig('child', 'children')
         ->children()
             ->arrayNode('children')
+                // ...
+            ->end()
         ->end()
     ;
 

contributing/code/standards.rst

@@ -148,9 +148,13 @@ Service Naming Conventions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * A service name contains groups, separated by dots;
+
 * The DI alias of the bundle is the first group (e.g. ``fos_user``);
+
 * Use lowercase letters for service and parameter names;
+
 * A group name uses the underscore notation;
+
 * Each service has a corresponding parameter containing the class name,
   following the ``SERVICE NAME.class`` convention.