Update documentation for Source#update

Some explanations are needed for update behaviour of non-automatic sources
under I/O pressure, in which case the consumer (OpenAL) may consume
faster than the producer (the caller of #update) produces and stop the
playback.
Fix unexpected stop when streaming

The stop is caused by OpenAL, the consumer of the audio buffers in the
streaming queue, consuming faster than the background updater thread
produces audio buffers onto the queue. As a result, OpenAL stops the
playback because the queue is empty, even though the producer still has
stuff to put onto the queue. The background thread is most likely
blocking on the I/O calls for most of the time (i.e., fread()) due to
I/O stress.

This also reveals a limitation about OpenAL: the consumer never blocks
as in a traditional producer-consumer model, in which the consumer waits
for the producer to produce more if the queue is empty. Now you may ask
how would the consumer exit finally, but that would not be a problem if
we can use some kind of special queue entry that indicates "end of
stream".

How to reproduce the issue:
1. Play streaming sources while at the same time playing several HD
   movies. This is to intentially create I/O stress.
2. Play streaming sources with a high-than-usual pitch and small queue
and buffer size. This emulates the scenario of consumer being faster
than producer.