Seek nearest SYNC does not adjust stale playlists

[stevemayhew]

getPlaylistSnapshot() can return a cached but potentially quite stale playlist that may be unsuitable for resolving a seek position.

This change fixes a race conditon that can cause a failed attempt to resolve a seek position with a stale playlist.

Pre-conditions for the race:

• A is the cached snapshot from previous playback of playlist A
• B is the selected playlist at time of the seek
• * — is current playback position in period
• QQQ — positions in A cannot be seek targets from B, they have rolled out from Timeline.Window
• WWW — are positions in A that cannot be resolved in A, but would be in A`

+=================*==+
|       Period       |
+=================*==+

     +QQQ-------+
     |     A    |
     +QQQ-------+
         +-------WWW+
         |     B    |
         +-------WWW+

           seek and switch back to A occur here...

          +----------+
          |    A'    |
          +----------+

The seek request is issued with Timeline.Window from playlist B, yet the call to getAdjustedSeekPositionUs() occurs:

1. After the current track selection swithces back to A
2. But before playlist snapshot A` is loaded, replacing the old A

The check is simple, does basic sanity check on targetPositionInPlaylistUs (that it is < durationUs of the selected playlist). This covers the positions WWW.