Any interface or control modules could request a timer from the player. This
player timer is like the player event listener except that:

 - It is only used to receive time update points0:

 - The timer is not locked by the player lock. Indeed the player lock can be
   too "slow" (it can be recursive, it is used by the playlist, and is it held
   when sending all events). So it's not a good idea to hold this lock for
   every frame/sample updates.

 - The minimum delay between each updates can be configured: it avoids to flood
   the UI when playing a media file with very high fps or very low audio sample
   size.

The time updated is the output time, unlike the on_position_changed event that
use the input time. It can fixes a very big delay between the UI time widgets
and the outputted content (depending on the audio output module, this delay
could be close to 2seconds).

The vlc_player_timer_point struct is used by timer update callbacks. This
public struct hold all the informations to interpolate a time at a given date.
It could be done with the vlc_player_timer_point_Interpolate() helper. That
way, it is now possible to get the last player time without holding any locks.

There are two timer types:

 - vlc_player_AddTimer(): update are sent only when a frame or a sample is outputted. Users of
   this timer should take into account that the delay between each updates is
   not regular and can be up to 1seconds (depending of the input). In that
   case, they should use their own timer (from their mainloop) and use
   vlc_player_timer_point_Interpolate() to get the last time.

 - vlc_player_AddSmpteTimer(): send a SMPTE timecode each time a frame is
   rendered. This timer use a different callback struct and data struct:
   vlc_player_timer_smpte_timecode. It's not possible to interpolate it, the UI
   should update its widgets once it receive the new timecode update. This
   SMPTE timer handle NTSC 29.97 and 59.94 drop frames and is frame accurate.