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.
How about:

```rst
But don't worry! Symfony's Config component will help us merge these values, provide defaults and give the user validation errors on bad configuration. Here's how it works. Create a ``Configuration`` class in the ``DependencyInjection`` directory and build a tree that defines
the structure of your bundle's configuration.
```

Then, for the example, I would stay consistent with whatever we're using so far. If we're using the   Twitter `client_id`, `client_secret`, let's keep using that. Regardless, let's use something better than `foo` and `bar` (I know, I am the king of over-using these). Your mailer config below is pretty good.