The title actually says it all, just extend current implementation
of PredictMarkerPosition() to cases when tracking happens in the reverse
order (from the end frame to start).
it's still doesn't solve all the ambiguity happening in the function
in cases when one tracks the feature and then re-tracks it in order
to refine the sliding. This is considered a separate TODO for now and
will likely be solved by passing tracking direction to the prediction