Switch target position from absolute to relative coordinates

this change allows us to use proxy footage with a lower resolution
Bugfix: need to handle pivot point similar for measurement and compensation

Problem was how the pivot behaves relative to a given target position.
For the measurement, we kept the pivot anchored relative to the reference
frame. But the way the compensation matrix is built effectively means that
the pivot is shifted to the target position (this is also a plausible choice,
since the target position represents the movement the user *wants*, e.g. a pan;
it seems plausible the user wants the pivot for rotation to travel with the
pan -- if this assumption is indeed apropriate needs further discussion though).
Bugfix: don't duplicate stabilisation data in track map

Track map is used for active tracks while tracking;
when refining a track while stabilisation is active, there is no need
to duplicate the stabilisation working data.

Without that fix, ownership is messed up, leading to memory corruption.
Bugfix: really use closest enabled marker for track initialisation

Previously we relied on BKE_tracking_marker_get, which contains magic to
fall back on the "closest" (actually next to left) frame, in case there
isn't an exact match.

Unfortunately, when refining tracks interactively, Blender has the habit
to set an additional marker to the previous frame with flag == disabled,
in order to mark the start of an active track segment. Thus, if we don't
observe the enabled state of a marker, we might end up using some arbitrary
incorrect tracking values, which just happen to sit in such a toggle marker.

When this happens during initialisation, these arbitrary values can poison
every other measurement value on that track and any other tracks chained behind.

The fix here is to re-use the search functions implemented for interpolation
of full gaps. This gives us the nice additional benefit of really picking
the marker closest to the the desired reference frame
Animation: access all possibly animated values through getter functions

in some cases we need to retrieve those values for a different frame than
the global "current frame". Seemingly, Blender doesn't provide infrastructure
for such a situation -- thus we need to build our own infrastructure.
Animation: allocate private working data (API CHANGE)

maintain a private struct for caching the F-curves.

Warning: the signature of BKE_tracking_data_get() has changed.
We need the full clip data, to be able to remap the frame number
to scene coordinates.
Animation: retrieve values from F-curves

On initialisation, do a lookup of existing animation F-curves.
This allows us to use the correct parameter values, especially
for initialisation of the per track reference frame and baseline values.
use animated F-curve values only when necessary

Using the global "current values", as placed by the animation system
into the data structures, has the benefit of immediately responsive
GUI controls. Thus we switch to fetching the values from F-curves
only when we know we're accessing other frames than the global
"current frame" -- that is, when initialising the track baseline values,
when interpolating over gaps and when calculating the auto-scale.