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.