video_output: report the correct time to clock

Since the video output cannot be the master clock, there's no reason to artificially change the date matching with the displayed frame. Indeed, the video output was using two points that felt weird:

• When the picture was late, it was "forcing" the timestamp by using VLC_TICK_MAX as system time.

• When the picture was rendered before the deadline, it was using system_pts, ie. the date at which the clock computed when it should be rendered, as the system time for the clock.

In both cases, it was basically only disabling drift computation in traces, since the drift is not used in the video output so changing its value doesn't change the behaviour and the clock points will never be used in a master clock. Drift would always be zero on the traces.

This commit re-establish the drift computation, using the time at which the frame is finished being displayed as system time. It won't match the "exact" time since it doesn't account display latency nor supports using dates from VSYNC (ref #26184) but the error will almost always be a constant part (for the latency not being used) plus a bounded part (for the VSYNC sampling delay), meaning that every non-stable behaviour like drifting can be measured.

Reference also commit 207fcd92 which tried to apply that to the clock wait.

Reference commit abb6e135 which asserted that drift should be 0 given that the whole sampling process is controlled by the clock, which is only true if the vout_display doesn't stall the video_output.

Reference commit 013aa3aa which started to use VLC_TICK_MAX (INT64_MAX back then) so that the clock update would notify the player.

Important: The intent of the commit above is disabled by this commit.

Note that this commit virtually introduce a huge initial drift. This drift is actually expected given that we draw the first frame regardless of the actual date, and playback constraints might have the video track earlier at the beginning than audio track.

This also introduce increasing drift when a frame is re-drawn, which is also by design since we didn't update the frame. A motion-interpolating filter would generate intermediate frames and avoid this, which makes it more representative of the true video output drift.