GSoC11 - "Local Space" for Transform Channel Drivers Rebooted

After much lobbying (in the form of countless bug reports and feature requests all over the place), I've taken a second look at the situation with the "local space" option for "Transform Channel" driver variables.

The good news is that I have been able to find an alternative solution for this, which means that we now have:

The "local space" implementation that most people have been expecting all along, which includes constraints but not parent/restpose info.

What about the old "local space" in 2.57/etc.?

For compatibility reasons, the old local space checkbox option has been renamed to "Transform Space". This option just takes the transforms that you can set via transform tools/buttons, without constraints or parenting/restposes getting in the way.

Among the benefits of this are that you can get location/scale transforms without needing to know all the details about the data paths needed for those.

With rotation, things are (as always) a bit more complicated. While with the other transforms, you can only ever have one representation for them, we have 3 different classes of rotation representations (Euler/Quaternion/Axis-Angle). Transform Channel dvars only return eulers, so the upside of using this dvar type over "Single Properties" (apart from not having to type out the paths yourself) is that you could for instance get out quaternion and axis-angle rotations as eulers.

What's taken so long for this to happen?
IIRC, I've only made two major changes to the way this worked since I originally implemented it, both of which were spurred by some bug reports.

Perhaps the most significant was for #20870, which was causing flipping artifacts in Durian rigs. The problem was that decomposing a matrix to get the rotation component (a necessary step if you need to get out the constraint-including results) results in non-unique results (a "one to many" relationship - thanks to buggered-up trigonometry ;) which would manisfest as flipping at 180 degree boundaries. At the time, the fix was to simply use rotations directly in this case if possible, while everything else could be decomposed safely.

I've since figured out/become aware of an alternative method, which is what I've committed.