Bugfix: Track auto fadeout

- fix merge error (use 1.0f otherwise feature doesn't work at all)
- fix erroneous assert. We want to ensure we're really outside the track range
Review: stylistic fixes
Review: upgrade and deprecation

- mark deprecated field in DNA
- include the word "deprecated" in RNA comment
- remove superfluous operator
- handle upgrade to new settings based on presence of fields in DNA
Review: use private allocation, remove working data from DNA

The measurement of image movements uses a constant "baseline" contribution
for each track, which is precomputed on initialization. Indeed this is
private working state of the stabilization algorithm and better handled
locally, instead of bloating the DNA
Review: reorder GUI controls

- group the track lists into a box
- use less hiding, more disabling of controls
- instead of grouping controls by location / rotation / scale,
  rather group by toggles, target position, influence
replace the trickery of auto-faded tracks by a real solution with interpolation

Beyond the area covered with usable tracking data, the stabilization function
will be disabled, causing the image to jump back to neutral position.
From a users POV this behaviour is surprising; rather you'd expect the image
just to stay as it was, i.e. we want the stabilization to stall in the end position
instead of jumping to zero.

Previously I had a bit of magic trickery built into the marker access function
(basically the original solution in blender used a similar approach at the same location)

But on second thought, I consider this non obvious magic and decided to go
for a real solution, which unfortunately is way more expensive in terms of code.

Now, in this reworked version, when we detect we're outside the definition range,
we actively search the nearest position still in definition range; then we
either hold that value (for extrapolation) or interpolate in case of a gap
in the middle of the definiton range.

NOTE: right now this solution is affected from the "automation problem"
in the same way as the autoscale function is: since we don't (yet) use the
correct automation values when we're measuring stabilization data for anything
*other* than the *current frame*, the interpolation/holding could produce
quite strange results. This problem will go away though, once we handle
automation values more correct in the calculation.