Time-code needed in read/write callbacks?

Currently, when you request a buffer-clear in the `sio_sine` example, you hear a brief pop---at least with the ALSA backend. This may or may not be due to a limitation in the backend, but it occurs to me that there may be a deeper problem:

If your buffer is filled with a sine wave, and you clear the buffer, then when you start generating the sine again... how do you know the correct offset to use so that the newly-generated sine wave is not phase-shifted from what was playing previously?

That pop you hear could very well be a waveform discontinuity due to the write callback not taking measures (or not _being able_ to take measures) to ensure that the phase alignment is maintained.

The sine wave stands in for more complex audio, of course. What if you're generating an interactive musical score in a game? Most of the time you may be able to buffer a couple seconds ahead, but then a sudden change is needed, so you request a buffer-clear. Then, in the write callback, you generate the new score segment---but where exactly are you picking up from? What was the last frame to play? You can't generate a seamless musical score unless you know the exact boundary of that buffer-clear.

This is why I think libsoundio may need to present some kind of time-code with respect to the audio stream. Because resolution down to a single frame---but no smaller---would be needed, I think this time-code would better be expressed in terms of an integer number of frames rather than floating-point fractions of a second.

For example, `soundio_outstream_begin_write()` could indicate that the first frame about to be written will be frame number 1504176. If you clear the buffer, then you may get that you're about to write frame 1408176.

(A possible related feature that would be nice is to allow the write callback to read the buffer that was nominally "cleared," in case it wishes only to modify the already-buffered data rather than generate it again from scratch.)