vo_vdpau: simplify previous vsync timestamp calculation

The strange thing about this code was the shift parameter of the
prev_vs2 function. The parameter is used to handle timestamps before the
last vsync, since the % operator handles negative values incorrectly.
Most callers set shift to 0, and _usually_ pass a timestamp after the
last vsync. One caller sets it to 16, and can pass a timestamp before
the last timestamp.

The mystery is why prev_vs2 doesn't just compensate for the % operator
semantics in the most simple way: if the result of the operator is
negative, add the divisor to it. Instead, it adds a huge value to it
(how huge is influenced by shift). If shift is 0, the result of the
function will not be aligned to vsyncs.

I have no idea why it was written in this way. Were there concerns about
certain numeric overflows that could happen in the calculations? But I
can't think of any (the difference between ts and vc->recent_vsync_time
is usually not that huge). Or is there something more clever about it,
which is important for the timing code? I can't think of anything
either.

So scrap it and simplify it.
vo_vdpau: document what WRAP_ADD does

This wasn't necessarily clear.
vo_vdpau: add an additional check for timestamp robustness

This might be a good idea in order to prevent queuing a frame too far in
the future (causing apparent freezing of the video display), or dropping
an infinite number of frames (also apparent as freezing).

I think at this point this is most of what we can do if the vdpau time
source is unreliable (like with Mesa). There are still inherent race
conditions which can't be fixed.
lua: add API for observing property changes

A low level API was added already earlier, but that was merely a binding
for the raw C API. Add a "proper" one, and document it.
command: property set commands should send property change notifications

Some of these property implementations already send notifications on
their own, but most don't. This takes care of them.

Of course this still doesn't handle all propertry changes - this is
impossible without special-casing each property that can change on its
own.
client API: avoid redundant property change events if possible

This is done simply by comparing the previous and current values. Do
this only if the requested format is not MPV_FORMAT_NONE.