es_out: trace wake up delay for input pacing monitoring

This patch adds a new metric to track and understand the behaviour of
the input pacing done from the input buffering values. The behaviour is
showing correct properties currently, but as will be shown later in this
commit message, this metric helps debugging pacing issues leading to
screen freeze.

In the work for making clock-start distributed across every clock
tracker, and because of a change removing the call to the function
input_clock_ChangeSystemOrigin, the input clock wake-up delay was not
computed correctly. Specifically, a huge delay of multiple hundred of
millisecond was appearing at the startup of the playback for file://
media, leading to a huge gap in playback.

The problem can be revealed when tracing the input_clock_GetWakeup
values. Those values are used to pace the input, and they are dates
matching with up until when the input is allowed to sleep, or 0 to
disable sleeping altogether. The value returned is valid up until
vlc_tick_now() is bigger or a new input_clock_Update() is made.

By substracting vlc_tick_now() to this date when the value is not 0, we
can get the time the input is supposed to wait before doing anything
else. The graph would typically look like this when the freeze was
happening at the beginning of the playback

       Input clock
         wake up
           ^
    330ms -|             +----+
           |             |    |
           |             |    |
        0 -| ------------+    +--------..
           +----------------------------->t

In the current state or after proper fixes for the input pacing were
done, it would display the following graph:

        Input clock
          wake up
            ^
            |
            +----------------------------->t
         0 -| ------------++--------------
            |             ||
            |             || 
    -550ms -|             ++

As such, a very high value looks suspiciously wrong, and improvement
could be made later to start the wake-up delay at -pts_delay immediately
instead of returning 0 as long as the reference point is not registered
yet in the input clock buffering subsystem.

This metric also catches additional artifacts that are generated by the
input decoder waits right at the end of buffering, which might be
interesting to investigate later.