Insert newView before measuring for LiquidOutlet.adaptSize()

This PR addresses the issues described in #49.

Prior to this PR, the following steps would occur when transitioning from oldView to newView with a parentView:

1. parentView would measure itself (thereby measuring the size of oldView).  
  These dimensions would be saved in `_lastLock` variables, and parentView would use these dimensions to set an explicit height and width.
2. oldView would be set to `position: absolute`, thereby emptying parentView of static elements.
3. newView would be inserted into parentView with `display: none` and `position: absolute`.
4. newView would measure itself.  
  Because it's absolutely positioned, it would shrink-wrap its dimensions.
5. newView would reset its `display` value (causing it to appear) and the animation would begin.
6. parentView would transition itself from the `_lastLock` dimensions to the newly-measured dimensions of newView.

From my perspective, there are a couple of problems here:

* oldView will shrink-wrap its dimensions when set to `position: absolute`.
* newView would measure itself while being `display: none`, which prevents the parentView from adapting to the contents of newView.
* During the transition, parentView is being laid out using an explicit height and width, which is never optimal.

After this PR, the following steps occur during the same transition:

1. parentView measures itself (thereby measuring the size of oldView).  
  These dimensions are be saved in `_lastLock` variables, but parentView no longer sets explicit dimensions upon itself.
2. oldView uses these measurements to set explicit dimensions before becoming `position: absolute`, thereby avoiding the shrink-wrapping problem.
3. newView is `show()`en after being inserted into parentView.
4. parentView measures itself.
5. The animation begins.
6. parentView transitions from the `_lastLock` dimensions to the newly-measured (and accurate) dimensions of newView.

My main concern is that this PR introduces two opportunities for flickering:

* parentView goes from its oldView size, to empty, to its newView size, and then back to its oldView size in order to transition to its newView size. This is imperceptible in the browsers I tested. The first oldView -> empty potential flicker could be mitigated by setting explicit dimensions until it's time to measure newView, but I don't think this is necessary.

* newView is now shown within parentView (to support proper measurements) before the animation begins. However, from inspecting the code, no tick occurs between the new call to `show()` and the old time in which Velocity would show the element at the beginning of the animation. This deserves some scrutiny and testing.

Naturally, all of the tests pass, and this fixes the problem shown in the test case here: http://ef4.github.io/liquid-fire/#/scenarios/inline

I was a bit verbose in my explanation because I personally struggle to wrap my head around animations. Hopefully this is a good level of detail—I don't mean for any of it to be remedial. Let me know if you could use any clarification.