constraints: start of reworked manipulator.

The manipulator is now significantly simplified. I recognized that there are (currently) three sources of motion for the manipulator: drag, velocity animation and constraint animation. We need to do something different for each when we hit a constraint, and the new code separates them so that we can cleanly do that. It needs debugging though, there are some discontinuities and bugs.
constraints: end of drag with no velocity must still honor any violated constraint.
constraints: don't cancel a constraint animation when it reviolates the constraint it's attempting to satisfy.

A constraint may specify an underdamped spring or something like that, where it takes the variable in and out of violation but doesn't want to be interrupted or recreated while doing so. Two more obvious bugs remain:
 - if the velocity imparted by a drag would take a variable out of violation (i.e.: you're flicking out of overscroll) then we shouldn't constrain; we should just let it go.
 - when dragging into violation the overdrag coefficient (currently a hardcoded 0.5, but eventually coming from the motion constraint so that we can do hard limits, etc) we apply the coefficient to the whole delta, not just the violating part of the delta. This is easy to fix if the overdrag coefficient is always just a number and not some non-linear function.

Eventually I want to support non-linear functions for drag coefficients and then use that mechanism for doing something like the iMessage relative springy scrolling.
constraints: better handling of overdrag coefficient enforcement.

This is still wrong if you start dragging when already in overdrag. Should only apply to the delta.
constraints: fully working overdrag, for linear overdrag functions (like the current hardcoded 0.5)
constraints: don't do constraint animation when the velocity from a drag would take the variable out of violation anyway.

This is the last obvious bug solved. All of the scrolling/frictiony things work pretty well now. I'm not sure if all of these rules will hold for a different simulation, like gravity.

Next I'm going to expand the definition of a motion constraint a bit so that they can be enforced hard (with optional rebound) or with springs. I should do some other examples, too, like the new mobile Google Maps pull up UI, which could be nicely expressed with constraints. With some more invention I hope to be able to express motion constraints that instead of preventing the motion of the variable that's being dragged instead respond to it. That will enable the iMessage style scrolling.