Slow I2C pin speed and set CH_TIME_QUANTUM to 0
Merge remote-tracking branch 'oliverlee/dev' into dev
Switch i2c back to 400kHz fast mode.
Prevent post-checkout from running on a file.
ChibiOS-RT update.
Rework of buffered writing scheme.

Notable changes:
  * Refactored buffer into SampleBuffer class
  * Write thread is a fire and forget type of thread
  * Protocol buffer encoding is only done once
  * Protocol buffer encoding is done directly to memory buffer
  * Each buffer has a little "extra" room at end to accomodate encoding
     going beyond actual buffer size; these excess bytes triger a call
     to f_write and all excess bytes are copied to the next buffer.
     This is the only time data is copied.
  * Three threads are spawed when collect starts:
   - control thread -- main high priority control loop, spawns manage
      thread
   - manage thread -- performs encoding and populating buffers and
      triggers creation of static write thread
   - write thread -- calls f_write on the date in the filled up buffer
  * Number of buffers, and their size (including extra padding) are
     configurable in SampleBuffer.h

TODO:
  Check each and every function call for errors.  At one point f_open
   was failing and it wasn't until over an hour before I pinpointed
   that as the cause of why files where not showing up.

  Figure out a way to categorize errors as fatal vs. non fatal and
  "do the right thing" when they happen.  In some cases printing to
  the shell or to a log file might be fine.  In other cases, we may
  need to shutdown.
WIP.  Still observing buffer overflows.

About to refactor write thread to be a static thread that puts itself
to sleep once it is done writing, and is woken up again by the manage
thread when a buffer is full and ready to write.
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.
Merge remote-tracking branch 'hazelnusse/buffer_overhaul' into dev