Unsolicited server responses cause RTSP streaming to crash

If the set up of the RTSP stream contains an incorrect or otherwise
problematic URL, some servers will send an unsolicited server response
that contains a negative number in the sequence number (CSeq) field.

This negative value is not returned from the function findPendingRequest(),
so the check in notifyResponseListener() will not work.  Instead there will
be a crash when 0 is used as the index to find a matching request/response
pair that doesn’t exist.

The fix is to return the received sequence number also when it is an
unsolicited server-client message.

Change-Id: Iedaba8a63dece7b43bce007069baefbfd10970b8
Bug fix for the MediaPlayer::prepare() api.

For an MP3 source, within the prepare command, ID3 tags are checked in search of
gapless playback info. This causes problems for streamed sources. If ID3v2 tags
aren't present, then a check is done for ID3v1 tags. This results in a read
command that asks the cache to jump to the end of the file, and subsequently
make an extra http call to request those bytes. For a streamed source, this
causes the file to not be downloaded automatically when MediaPlayer::prepare()
is called, and causes stuttering and extra buffering time to be needed when
start() is finally called.
The solution is to ignore the ID3v1 tags as the gapless info would never exist
there, and only check for ID3v2 tags.

Change-Id: I7d1b94cffbfe7c38ca094834dedbc92a58855e20