Adds design modes support to SC.Pane, allowing the design of an application to very efficiently and easily change depending on the width of the display.

While a design may be flexible for a wide range of display widths, at a certain point it no longer makes sense to keep stretching or compressing views and instead it is better to completely alter the design.  A prime example is that a design that can flex between a medium sized display like a tablet and a large sized display like a desktop, will not likely work for a small display like a smartphone.  In order to very easily alter the design, SC.Pane provides the designModes property which includes the width thresholds that you want to trigger a change to the overall design of the application.  Each time a threshold width is crossed, the child views will be updated with the new design mode.  At this point, any properties dependent on 'designMode' will recompute allowing you to adjust settings such as isVisible.

As well, SC.View has a new property 'designLayouts' that is simply the layouts for the 'designModes' you define.  For example, if the design mode becomes 'small' any child view that has a 'small' designLayout will have its layout automatically set.

This completes work spec #843.
Removes leftover code.
Adds automatic design mode class name addition.  If the pane implements designModes and the current design mode is 'large', the pane and its childViews will get a 'large' class name added.  This allows the developer to write CSS like this:

    .my-view {
      &.small { line-height: 24px; }
      &.large { line-height: 36px; }
    }

I found that almost every view in a design mode of the app needed small adjustments to their CSS for the current mode.  While it was possible to use classNameBindings on to the 'designMode' property, it ended up being used on almost every child view which meant a lot of repeated typing, plus classNameBindings would have resulted in an additional observer on each child view.  Since design mode changes are distinct events in the app, we don't need to bind them up and can do it much more efficiently with a direct approach.
Refactors design mode out of SC.Pane and into SC.Application.

- This makes it easy to set designModes only once per application, instead of having to set it over and over per pane.
- Also fixes application of design mode to take into account the mode that the view may already be in and thus we can exit early.
- Switches designLayouts to designAdjustments, so that you don't have to set a full layout for each mode.
Adds design mode(s) tests (currently failing - to be updated to new API).
Tidies whitespace.
Fixes design mode tests to match the updated API.
Removes observation of designModes on SC.Application.  These should just be set one time or else not used at all and we can do without the binding.
Improves design modes documentation and binds the current design mode back to the application.
Fixes bug if no newAdjustment exists but we are unsetting a previous adjustment for design modes.
Adds a necessary run loop for assigning the new design mode on resize events.
Removes the false assumption that non-iOS, non-touch event supported content doesn’t have any orientation. This allows orientation specific designs even on desktop (i.e. resizable) browsers. Renames the orientation body classes to ‘sc-portrait’ and ‘sc-landscape’ since they are being applied by SproutCore.

Also serves up @2x stylesheets when the devicePixelRatio is greater than 1, so devices that have a DPR or 1.5 get scaled down 2x graphics rather than scaled up 1x graphics. This matches the way that SC.Module serves stylesheets as well.
Refactors the design mode API to support orientation as well as the arbitrary application of any design mode specific properties (e.g. isVisible or rowHeight).
Fixes left over unit tests for design modes API changes.