Migrate back to mixins for Sencha Cmd and Architect compatibility

[johnyanarella]

Sencha Cmd has introduced an optimizer step (now enabled by default for Ext JS apps) that does not support custom class preprocessors. Class preprocessors were recently marked as private and are no longer an encouraged extension mechanism for the Sencha frameworks; a class preprocessor effectively reserves certain keywords across an entire codebase.

The solution moving forward needs to be in alignment with the documented public Sencha Framework APIs, to ensure a solution that will be supported in the future.

We discussed this with Sencha at SenchaCon, and the recommendation was to move to mix-ins, as these are the supported extension mechanism.

This comes with a few added benefits:

• it plays well with others - we're only reserving keywords within the class definition that has been decorated with that mix-in;
• it plays well with Sencha Architect;
• it eliminates several class dependency timing issues that tend to trip developers up when the first try Deft JS in their apps (ex. Ext.Component not being available at the time Deft JS is included, etc.).

Because this is the supported extension mechanism, in the event we have difficulty or need additional extension points, Sencha is more likely to assist in addressing those issues (as opposed to unsupported or undocumented approaches).