write_thread_ is now a static thread.

Write thread is now a static thread and sleeps for 10ms, then checks whether
the active buffer has changed; if it has initiates a write.  The active buffer
is now a class data member and is only modified in the manger thread.  The
manager thread locks a mutex when it modifies it, and the write thread locks a
mutex when it reads it.

The thread priorities are now stacked such that the control thread is highest,
then the manger thread, and finally the write thread.  CH_TIME_QUANTUM is 0 so
the design relies on each thread yielding/sleeping to make sure others aren't
starved.

Initially tests indicate that no write errors are occuring, however it is
possible that the write thread is not able to keep up, in which case the
manager thread will eventually "lap" the write thread and we would start to see
data corruption.  I think it should be possible to detect this by examining the
difference between SampleBuffer class data member active_buffer_ and the write
thread local variable buffer_to_write; if this difference every exceeds
number_of_buffers - 1, there will likely be problems.