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.
Workaround: disable track weights for initialisation

this workaround allows to use track weights in practice, while the proper
access to keyframed values is not yet implemented.

Explanation: for initialisation, we need to pick the measured values at
various reference frames, which are obviously not at the global "current frame"
position and thus don't hold the correct keyframed values. Typically this leads
to baseline values not being picked up at all (when the respective tracks
have been faded out through animation)