Symbian audio backend reports incorrect processedUSecs value at end of push-mode playback

This defect was introduced by change 6fc92ea9

When playing in push mode, the value returned by processedUSecs() at the
end of the stream is incorrect. This is shown by the fact that the
following test case fails:

1. start() in push mode
2. provide P bytes of audio data
3. suspend()
4. processedUSecs() provides a value X which appears to be correct,
i.e. X < P
5. resume()
6. provide a further Q bytes of audio data, and wait a sufficient period
for all of this data to be played
7. processedUSecs() now returns a value Y which is incorrect, i.e.
Y != P + Q

This appears to be due to the underlying DevSound implementation returning
an incorrect value from SamplesPlayed().

The reason why we do not see this defect in pull mode is that here, the
audio backend is able to determine when the last buffer has been received
from the audio source (by checking QIODevice::atEnd()), and mark this buffer
with the LastBuffer flag when it is provided to DevSound. When the audio
subsystem reaches the end of this buffer, it raises an underflow error by
calling MDevSoundObserver::PlayError(KErrUnderflow). The audio backend
reacts to this callback by setting its m_underflow flag. This flag is
checked in the implementation of processedUSecs(); if the flag is set, the
backend corrects the SamplesPlayed() value by rounding it up to the number
of samples actually provided to the DevSound implementation. Step 7 in
the test sequence above therefore passes.