video_output: reset chrono on Request and Flush

Chrono are estimating the duration of the rendering when displaying frames, but they were only initialized at the vout thread creation, and not whenever the decoder outputs a different format (eg. because it's a different decoder). It means that when rendering a 8k 24fps frame, and then 360p 60fps picture, we'd expect that the first frames from the 360p stream renders with the same timing as the 8k 24fps, which could lead to useless drops. vout_Request was usually followed with a forced picture, which helped mitigate the issue, but the chrono are averaging with previous values, leading to local increase of expected rendering time at the beginning.

Likewise, when flushing, timing constraints could have change, though admittedly there is less obvious reason for the constraints to change in this case. It still solves issues in the following cases:

• The framerate matches the refresh rate and the offset-to-VSYNC has changed. It would reduce or increase the rendering time virtually without controls from VLC.

• The rendering has been paused by a debugger at the middle of the measurement. It would artifically set chrono to a very high value, like 30 seconds, which means that a frame must arrive 30 seconds in advance from the decoder to the video output to be displayed.

Rationnally, the chrono system is a heuristic to fast-forward the video pipeline when the stream cannot be rendered in normal condition and resetting the timestamps would not break already working streams, whereas it would only display at most one more late picture in the broken stream, which was already the case at the beginning of the stream because of forced pictures.