Solving rewrite conflicts with php 5.4 trait

Assumption:  magento-hackathon/Responsive-Email-Templates-with-CSS-Inliner is installed and also one of the Ebizmarts or Aschroder extension

This is a POC to make sure that your rewrite of Mage_Core_Model_Email_Template will always rewrite that class independently of the module loading order.

I do not expect that this will be merged. As usually Magento runs on PHP 5.3 ;-) and traits are introduced in PHP 5.4.0. 

The rewrite is done via an observer. This solves the problem of a rewrite of a rewrite.

With this "pattern" neither Magicento nor n98-magerun will show you a rewrite conflict. 

So use this mainly in your own local codepool where you know that the rewrite will happen via an observer.

The following example is too weird but it could be a real life one.

```
$  php n98-magerun.phar dev:module:rewrite:conflicts
┌────────┬──────────────────────────────┬────────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────┐
│models  │core/email_template           │Aschroder_SMTPPro_Model_Email_Template,                     │Zookal_Core_Model_Email_Template                            │
│        │                              │Ebizmarts_Mandrill_Model_Email_Template,                    │                                                            │
│        │                              │Hackathon_ResponsiveEmail_Model_Email_Template,             │                                                            │
│        │                              │Zookal_Core_Model_Email_Template                            │                                                            │
└────────┴──────────────────────────────┴────────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────┘
1 conflict was found!
```

But what if your local extension starts with the letter B instead of Z?

Magicento and n98 will of course still show rewrite conflicts but with the observer you can create a new local class (like Zookal_Core_Model_Email_Template) which solves all the rewrite issues and extend the community classes from each other (if no conflicting methods are available)

If Hackathon_ResponsiveEmail would use the observer rewrite pattern ... then module loading order must be considered.

There is also a tiny performance decrease with observer.

Any thoughts?