[WIP] Use real builders for the ORM

Since I know @merk is also refactoring the code, I think it's time to show my progress on implementing real builders for the ORM version

### Why this pull request:
This pull request tries to fix the problems described in https://github.com/FriendsOfSymfony/FOSMessageBundle/issues/184 (Yeah I really wrote that :scream: :open_mouth:)


### What has changed for the ORM

##### Real builders for new thread and reply actions
- This allows to fully unit test those objects (No more things like https://github.com/FriendsOfSymfony/FOSMessageBundle/pull/166)
- And makes ite easy to extend them (see the example I added)
- Importers are easier to write
- Objects are more bullet proof by also having guards in the builder. (we want to create valid objects!) Those who programmatically send messages will have a harder time screwing things up

But making that work with the current flow has forced me to...

##### Changes to the form handlers

I did that by
- creating a new form_orm.xml and a form_mongodb.xml element which gets loaded depending on your database settings
- The form_orm.xml document now has new services to the handlers
- The form_mongodb.xml still uses the old handlers so the old flow

From there one it's quite straight forward. 

#### The composer service is no longer needed (orm)
I no longer rely on the composer to create a new default object. Since I don't want those objects created if they are not valid.

#### The sender service is no longer needed (orm)
Ahum magic and stuff....

#### It is replaced by an actionsmanager
The actionsmanager is responsible for sending the thread object to the persistent storage. I need this extra step because we need  both managers for updating a thread. So it's a facade. But it's also the ideal place for dispatching the events. (todo)

#### What does this all mean for the ODM

#### I have not tested the ODM version, for all I know it's broken and even the config doesn't work!
This is the reason I decided to share this work in progress code now. If there is **no** chance that this code gets implemented than I'll have to maintain a fork. And  then this becomes a non issue for me **for now**. (The coder in me wants to have both versions working, but time constraints would force me to make it not a big priority.)

But basicly the ODM version would need real builders too. Then they can share the same code flow from there on.