Extend data model to support reworked implementation

The changed implementation of 2D includes additional parameters
into the generated coordinates for the stabilised movie clip.

 - additional flag enum to mark a track for rotation stabilisation use
 - the exiting field rot_track is now obsolete
 - introduce a anchor frame number; this frame defines the reference position
 - introduce a target position to be compensated (to allow for panned shots etc)

Moreover, the more precise implementation of tracking conrtibutions
requires to have a precomputed baseline contribution for each track,
since tracks may start at different frames

NOTE: the added RNA definitions are more or less guesswork --
I have a rather rough understanding of how thos RNA bindings work.
Calculate averaged translation and rotation contributions

Completely reworked the foundation of the algorithm.
Now, translation and rotation are treated similarily, and rely on each other.

Moreover, we now treat each track individually, and calculate a real weighted average
Each track provides a normalised contribution, both for translation and rotation.

TODO: the initialisation of the baselines per track
Initialize baseline contributions per track

- settle down about when to use tracking data, and when to detect a gap
- introduce flag to mark "initialized" state per track
- adapt the average calculation to include only initialized tracks
- define a new (virtual) ordering of tracks, based from the distance
  of each track's reference point to the global anchor_frame
- this order allows a correct bootstrap of the baseline contributions,
  since we start calculation as close as possible to the anchor_track

This commit makes the reworked calculation functionality basically complete.
Next step will be to adapt the top level functions and thus to swap the new
mechanism in place
Change toplevel calls to use the rewriten functionality

Unresolved: how to initialize the auto scale factor
Integrate autoscale function and remove now obsolete median calculation

This completes the rewrite of the stabilisation engine core.
Extend and reorganisze GUI pannel for 2D stabilization

- several new data items accessible through the gui
- regroup the controls, to integrate the new settings
- introduce new logic to show/hide the stabilization track lists
- add new operators and RNA to handle the collection of rotation tracks
- replace single rotation track in the UI with a list of tracks
- improve UI documentation strings
Migration entry for Blender 2.61 <= ver < 2.70

- According to Git, 2.61 was the first version to include
  the tracking.stabolization.rot_track field
- migrate this field by setting the corresponding flag

NOTE: need to adjust the final version at which this migration kicks in!
Build compenstation from measured data

For the 2D-stabilisation to work properly, it is necessary that the
transformations to compensate the movement are built in accordance
with the way the measurements for the individual contributions are
retrieved.

Most notably, the rotation must be performed around the same center,
which was used to determine the angular contribution. Currently we
use the translation compensated center of frame at the.

In terms of code organisation it is better to separate the *measurement*
from the construction of a compensating function. This means that the
translation parameter should not contain any scale adjustments, since
such adjustments are a detail of how the compensation is done, and
actually might be done in multiple ways.

TODO: I have yet to figure out how to build the processing chain
for the compositor nodes in a similar fashion. I doubt the default
rotation works correct for our case. Anoter unsolved problem is
how to get the animation running (it works when played back in
the clip editor, but not in the sequence editor)
Better handling of track ends

now using a smooth fade out, to prevent jumps at the start / end of tracks
Consistent handling of pixel aspect and canvas size

With this change
- all tracking data is defined in terms of the expanded canvas size (square pixels)
- every rotation and angel calculations happen in this expanded canvas
- we distinguish consequently between canvas size and image buffer size
- the tracking measurements get the effective aspect (canvas aspect) as parameter
- also the pivot point for rotation is defined in canvas coordinates
- the order of the final stabilization transformation is changed accordingly,
  so that the scaling too happens in canvas space. We expand to squar pixels
  as first step, and compress back to display pixel aspect as last step
New Feature: Support for Zoom / Scale stabilisation

After all the refacturing, this is low hanging fruit now. Since any rotation
is basically a linear transform, we can as well pick up the scale factor
relative to the rotation pivot point.

To be able to handle this scale information in the existing framework,
we determine the vector lenghts at the reference frame, plus we use the
averaged scale at that frame as baseline. The individual contributions are
recorded on a logarithmic scale, to allow caluclating weighted averages.