better time-pos behavior

Pulled out from https://github.com/mpv-player/mpv/pull/13614#issuecomment-1975322056

Another convenience may be a better version of time-pos that isn't dependent on video frame rate or synchronization, but a property that represents where the playback "should be". time-pos is discrete and locked to the frame rate so the resolution isn't always sufficient, and audio-pts isn't guaranteed to be in sync, is nil during seeking, and isn't even guaranteed to exist for files without an audio stream. For example, for a 10fps video, the new property would be able to return something like 0.35317865 when it's on the 4th frame, rather than 0.300. And if a/v gets out of sync, it doesn't return where the audio playback currently is, but the target time the video and/or audio stream is trying to sync up with. So if it skips a few frames or needs to adjust audio or something, the property keeps increasingly at a constant rate as if nothing happened.

https://github.com/mpv-player/mpv/pull/13614#issuecomment-1975399280

If it wouldn't break much, perhaps this new property could replace time-pos, since in most cases it should be functionally equivalent or better. And then the current time-pos would get renamed to video-pts since that name doesn't exist yet, and for video files that's basically what time-pos is.
Then you'd end up with video-pts and audio-pts representing the actual time of each stream and time-pos is what they're both getting synced to, if that makes any sense

Review PR #13614 and the linked discussion first; the issue identifies no source files or tests. Define the new playback-position semantics, including seeking and streams without audio, and determine whether the existing time-pos property should be replaced or renamed as proposed.