Marker: hold unique reference to TrackPoint.

[dennisguse]

OpenTracks only allows to create Markers if a valid location is available (i.e., a TrackPoint with location was stored).
However, in the current implementation the TrackPoint and Marker tables are independent (i.e., Markers also store lat/lng, altitude etc) and they are just indirectly linked together by time.
In addition, Markers have the duration and length (here distance) for being rendered on the charts.

This PR changes this on database level by adding a reference for each Marker to one TrackPoint.

However: Both GPX and KML allow to import Markers that are not related to any TrackPoint within a Track.

This implies that people might have Markers that cannot be linked to a TrackPoint - they might not even be close to any TrackPoint (in time as well as location).
Even worse people might have imported such Tracks on purpose to show the Markers with OSMDashboard or just to store all their tracking data in OpenTracks (from other application).

Question: Should OpenTracks internal data model reflect how OpenTracks works or rather keep the existing functionality?

PS/ I am not even sure that the functionality was intended this way...

[dennisguse]

@rgmf @pstorch do you have an opinion about this?

[hercek]

Well i do not personally care about markers but I would expect them to work like this:

1. They are shown on OpenTrack charts only when they belong to a track point based on location or time. They must be close to the track point location within track point length (and maker size). Or their time (middle of their duration) must fall into track point time. One makers should belong to best fit track point if any.

2. They should be shown always on maps and only based on their location. The mapping software can provide filtering based on maker time/duration. But this is not an OpenTracks issue.

[dennisguse]

I thought about this and we leave it as it/was aka a Marker may be related to a TrackPoint, but we may have imported data and then this may just be not true.