Refactors SC.RenderContext to simplify the API, introduce consistent naming and make it behave appropriately.  This should remove the guess work about whether a function is or is not supported by the context and make it easier to remember the names and parameters of each method.

- There are now 3 similar access methods:  attrs(), classes(), styles()
- There are now 3 similar add methods:  addAttr(), addClass(), addStyle()
- There are now 3 similar remove methods: removeAttr(), removeClass(), removeStyle()
- There are now 2 similar reset methods: resetClasses(), resetStyles()
- Fully backwards compatible.
- Duplicate and inconsistent method names have been deprecated:  css(), html(), classNames(), resetClassNames(), attr()
- Adds several Developer Warnings to aid developers in updating their code (in debug mode only as not to take up space in production).
- Removes some code duplication and simplifies the code.
Fixes bug noticed by updated jQuery.  The previous version of SC.RenderContext:addStyle() would replace styles, which was really only due to an undocumented behavior of jQuery, plus it is semantically incorrect for 'add' to replace.  The refactor of RenderContext makes the functions behave properly.
Updates all render context methods to use the updated API.  This should make it clearer that the context is not a jQuery object and shouldn't be used like one.
Fixes typo of missing '@' on endif, which would cause non-debug builds to become invalid.
Fixes improper use of execUnsafeLocalFunction polyfill so that jQuery tests work properly.
Makes invokeNext trigger the next run of the run loop if none is scheduled.   This makes invokeNext the appropriate method to use when needing the DOM to be up-to-date before running code against it.

Previously, invokeNext functions would not run until the next run loop occurred, which if there were no events or timers, might mean that the code won't run for a long time.  While invokeLast lets you put code at the end of the run loop, the DOM will not have yet been updated and invokeLater is risky to use at small intervals, because if the interval is too small, the invokeLater code will run in the current run of the run loop and again the DOM will not have been updated.  Instead, invokeNext now ensures that the run loop completes execution and schedules an immediate timeout in order to allow the browser to update the DOM.

This works with the timer additions to the run loop, so additional run loops only run once even if there is an invokeLater expiring at the same time as the invokeNext timeout triggers a new run loop.

- Includes unit test.
- Fixes bug in previous unit test that left a run loop unfinished.
Fixes CoreTest.Runner to start on the updated jQuery ready event.
Improves the documentation for invokeNext.
Makes the rendering of animation layouts asynchronous always to ensure that the current layout of the View gets rendered to the DOM.  If the current layout is not rendered, the animation layout will be all the DOM sees and thus it won't trigger an animation change.   This should make using SC.View:animate much easier, especially for new developers.

Also scrubs layout_style.js to remove a number of unused variables, support the above change and optimize the variable declarations.  This optimization dropped the minified file size from 9,322 bytes down to 8,914 bytes (408 bytes reduced).
Cleans whitespace.
Cleans whitespace.
Refactors transition and animation testing of SC.platform; adds SC.browser.cssPrefix, SC.browser.domPrefix and SC.browser.classPrefix; adds SC.browser. experimentalNameFor(), SC.browser. experimentalStyleNameFor() and SC.browser. experimentalCSSNameFor() methods; and adds SC.UNSUPPORTED constant.

There were many problems with the animation and transition tests that existed before.  There was no forward support so browsers, like the Firefox nightly that have dropped prefixes, would fail to identify as supporting transitions and transforms.  Also, animation event listeners were hard coded into RootResponder for webkit only.  Also the event names needed to be forward supported as well and because there is no consistency in the event naming, the real transition and animation events may not have been captured on certain browsers.

Now, SC.platform does quick and precise tests to determine the actual event names allowing the RootResponder to listen only to the properly named events rather than using a shotgun approach with a bunch of different browser prefixes.

To make the code forward compatible for when prefixes are dropped, SC.browser has three new support functions:  experimentalNameFor(), experimentalStyleNameFor(), experimentalCSSNameFor().  These functions return the proper name for experimental names for object classes & properties, DOM properties and CSS attributes, not by guessing, but by testing the standard name and then testing prefixed versions of the name if necessary.  This allows developers to avoid writing code like:  SC.browser.cssPrefix + "box-shadow black 0 1px 2px", which will fail on browsers that no longer need a prefix and instead use:  SC.browser.experimentalCSSNameFor('boxShadow'), which will return either "box-shadow", some browser prefix + "box-shadow" or SC.UNSUPPORTED (allowing you to do something else).

- The css prefix and dom prefix were calculated from the user agent, which duplicated work already done with more rigor in SC.browser.
- Fixes duplicate 'input' property in SC.platform.
- Deprecates SC.platform.cssPrefix and SC.platform.domCSSPrefix.
Updates test to use proper domPrefix value rather than the deprecated version.
Refactors SC.View:animate().

- animate() uses invokeNext() so that the developer never needs to monkey with the run loop in order to call animate().  Animations will only begin after the browser has had a chance to flush any changes to the DOM, thus ensuring that the animation actually occurs.  This will make using .animate() much easier whereas previously, developers would revert to invokeLaters to try and make sure the DOM style existed before animate would adjust it.
- the animate() function can now accept a target argument as well as a method, which conforms to the standard used by many methods in SproutCore.
- if no target it given the view itself will be the value of `this` in the callback.  Previously, this would be the layoutStyleCalculator, an internal object of SC.View.
- the animate() function is thoroughly documented now, including notes on how to hardware accelerate position changes.
- uses new additions to SC.platform and SC.browser to make animations forward compatible and fixes animate() on Firefox nightly
- hardware accelerated styles no longer remain in the DOM after the animation completes (i.e. sometimes the translate values would stay in the style)
- resetAnimation() has been renamed to cancelAnimation(), because reset indicates 'revert', but the default behavior doesn't revert the layout.
- added SC.ANIMATION_POSITION constant for use by cancelAnimation().
- fixes hasAcceleratedLayer to be dependent on the layout.  Previously, adjusting a non-accelerated layout to an accelerate-able layout failed to update the property and hasAcceleratedLayer would be incorrect.
- cancelAnimation() can now cancel an animation and adjust the layout to its current value during the transition, to its original value or to the final value which is the default.
- adds a private `liveAdjustments` property to SC.View, which will return the current value of properties that are being animated.  This even works for accelerated transitions that use transforms and return CSSMatrix values while animating.
- simplifies the code somewhat and cleans up a lot of loose ends that remained since the original code was largely copy-pasted over from the old animation framework.
- removes an observer on the view's layout from within the layoutStyleCalculator and properly chained up the dependencies to remove some manual notification code.
- includes new unit tests
Extends the cleanup callback for the platform event tests.  This helps to ensure that the event comes in even if the browser is busy, before the fallback clean up occurs.
Further refactors animation and the calculation of layout styles by replacing the LayoutStyleCalculator instance with a single LayoutStyleCalculator object.  Previously, each SC.View created an SC.LayoutStyleCalculator object that it used in a truly dubious manner.  The LayoutStyleCalculator was supposed to be a group of functions that could be shared between all views, but instead each view had to create and modify its own instance of the calculator.  The calculator had several internal state variables which meant it could not be shared between views.  The calculator also cross-referenced the view itself and was never cleaned up resulting in a memory leak.

This update untangles the view from the calculator so that the calculator can be shared between views (not really much reason to even have this separate, but none-the-less…) and fixes the memory leak of SC.LayoutStyleCalculator instances.
Updates and corrects tests to work with refactored layout style code.
Removes developer warnings in SC.browser from non-debug builds.
Fixes problems with SC.View's animate() refactor.  First, the original layout hash was being altered for animation before being cloned when it should have been cloned first.  This mean that if the view had not yet been rendered, it would have been rendered with the altered animate layout the first time.  Second, willRenderAnimations could be called before the animation layout was applied if the view had not yet been rendered, which would result in the animation styles being applied too early.
Fixes problem with previous invokeNext() change.  If a run loop timer is fired in the current run loop and therefore unschedule's itself, it didn't reset the internal _timeoutAt variable which meant that attempting to schedule a new run loop timer would not work.

Includes unit test.