Implements first version of transition plugin support for SC.ContainerView.  Instead of simply swapping views, SC.ContainerView can now be given a transition plugin that it will use to animate the swap.  This commit includes a few useful transition plugins PUSH, DISSOLVE, MOVE_IN, REVEAL and FADE_COLOR and a protocol, SC.TranstionProtocol, that a developer can use to build custom transitions.
Fixes transitions addition to SC.ContainerView.
Makes it possible to use an SC.View instance or class as the original nowShowing value of SC.ContainerView.
Adds unit tests for transition plugin support in SC.ContainerView.
Fixes SC.ContainerView transitioning on awake with current nowShowing value.  Improves each transition to allow for multiple transitions to be called before each is completed.  Fixes the value of 'isTransitioning' while multiple transitions are in effect.  Makes all methods except 'run' of SC.TransitionProtocol optional.
Uses the new liveAdjustments property to get the current position of the view even if it is being transformed for the transition.
Updates SC.ContainerView to work with updated animate method which doesn't require manually calling invokeLater.
Tidies code.
Adds SC.ContainerView statechart diagram.
Completely refactors the transition implementation for SC.ContainerView in order to properly support multiple nowShowing changes with transition animations.

After struggling to make the container view handle multiple nowShowing changes while the previous items were still exiting, I had to step back and draw up the proper statechart for the container view to try and figure out why I couldn't get certain transitions to behave exactly as they should.  I determined that the container view's states are very basic, but what was missing was that each content view needed its own statechart in order to manage its own state.  For instance, a content view may be told to exit multiple times while it is in the process of exiting and the number of times it is told to exit may effect its transition.  Therefore, I added a simple statechart, SC.ContainerContentStatechart, that the container view can create for each new content and give control of the content's transitioning to.  This makes it possible to do very complex transitions, such as the PUSH transition that adjusts its exit animation accordingly to account for being pushed off before even being fully pushed on.
Forces the transition to be the same for all content statecharts.  This prevents multiple transition plugins from occurring in the content statecharts, which would be messy to manage and less performant.  If a view should have a different exit transition from its entrance transition, the proper transition plugin should be created and assigned.  This fixes a bug where setting the transition later doesn't update the current content view to use it.
Updates transition support tests for refactored code.
Changes SC.ANIMATION_POSITION API.final to 'end' because final prevents minification.  Changes SC.ANIMATION_POSITION.original to 'start' to better reflect the outcome with respect to 'end' and 'current'.  Adds missing animation unit test for cancelAnimation with SC.ANIMATION_POSITION.start without transforms.
Improves the PUSH animation to be more fluid (avoid cancelling the entering and exiting animations) and fixes a regression where the initially set nowShowing would transition on when it shouldn't.
Changes the internal classNames of SC.Theme to be an Array rather than a CoreSet.  Having it as a Set makes no sense and the amount of property overloading is ridiculous.  We have to check for Objects, Arrays, Strings and Sets, which is a waste of code rather than just standardizing on an Array like classNames is on SC.View.  Also, this causes problems if developers use the theme's classNames and assume it will be an Array like with SC.View.

This is a potentially incompatible change, but it actually fixes current code that uses the theme's classNames with the updated SC.RenderContext API so it should potentially work with any current code.  Also, because this API is so under-used, hopefully it will not affect any implementations.  Though, if it does cause actual backwards incompatibility, it will have to be reverted for 1.10.
Fixes some documentation for proper jsDoc usage.  Renames the SC.ANIMATION_POSITION enum to SC.LayoutState, which follows the JavaScript style guideline for enums and better illustrates that it is a state not necessarily a position (i.e. animating opacity doesn't effect position).
Provides backwards compatibility for providing the callback inside of the options object and adds warnings that only the standard arguments should be used.  Fixes #861 for 1.10.
Fixes placement of Developer Warning and updates the test to remove improper use.
Adds a developer error message if an SC.View is created using an existing layerId.  This should prevent some weirdness from occurring.
Fixes a regression with SC.CollectionView that occurred after a previous fix to remove a view DOM leak.  SC.CollectionView previously created a view with the same layerId as the view to be replaced before replacing it, which only worked because of some weird logic external to the CollectionView that used to prevent a view from being able to find its layer if it didn't have a parentView (which was also the cause of a leak because the layer might still exist in the DOM).  In any case, having two views use the same layerId at the same time is a bad idea.

So instead we essentially use removeChild().insertBefore() rather than insertBefore().removeChild() (i.e. replaceChild()).