feat($animate): allow $animate to pass custom styles into animations

[matsko]

$animate now supports an optional parameter which provides CSS styling
which will be provided into the CSS-based animations as well as any
custom animation functions. Once the animation is complete then the
styles will be applied directly to the element. If no animation is
detected or the ngAnimate module is not active then the styles
will be applied immediately.

BREAKING CHANGE: staggering animations that use transitions will now
always block the transition from starting (via transition: 0s none)
up until the stagger step kicks in. The former behaviour was that the
block was removed as soon as the pending class was added. This fix
allows for styles to be applied in the pending class without causing
an animation to trigger prematurely.

---- DEMO -----
https://s3.amazonaws.com/angularjs-dev/ng-animate-piggyback/index.html

[IgorMinar]

Should the mixed in style be removed once the animation is done?

I'm on cell so can't do proper review but from what I've see this looks good.

[matsko]

The styles should persist. If you look at the demo, you'll see that the goal is to place the box at the given coordinates. The animation that runs in between is just extra. If we removed the styles and if there is no animation or if ngAnimate is not activated then nothing would happen.

[tbosch]

I don't like that the styles are added via addClass as a third parameter, and as @IgorMinar mentioned, that there is no way of removing them.

I would prefer an addStyles and removeStyles method. This shouldn't be a problem now as you collect all changes until the next turn of the digest loop, right?

[IgorMinar]

landed as e5f4d7b and 02be700

[caitp]

The problem with this, as has been mentioned previously, is that

1. it adds totally unrelated functionality to a routine with a specific purpose, which is just not a very good API design (both for users, who will have a harder time finding out how to use this feature, and for maintenance, because it's more bits and pieces to reason about when fixing the inevitable bugs)
2. it makes it harder to fix the "sometimes async, sometimes not" issue in setClass()

I think this could have been done better, this should not have shipped yet =\ now we can't even fix it without breaking changes u_u which means we can't really fix it