Changed to while loop in UBX byte handling

Many changes which affect audio/log timing:

- Handle bytes from u-blox module using while loop instead of one at a time. This reduces latency and prevents buffer overflows.

- Write to log one line at a time instead of in "chunks". This means less time is spent writing in total.

- Write/flush when the audio buffer is nearly full, instead of when the most recent audio buffer read was small. The difference is, if a delay occurs during the read, the new method will delay a write until the audio buffer is full.

- Reduced audio sample rate from 31250 Hz to 7812 Hz. This quadruples the effective size of the audio buffer.

- Added linear interpolation of audio samples to give smoother waveforms. The PWM frequency is still 31250 Hz, but 3/4 of the samples are interpolated.

- Changed to FS_TINY to free up a bit more memory. With large audio and logging buffers, the time spent switching from reading to writing isn't a problem. Context switching seems to add about 20 ms to read/write calls when they are interleaveOn the whole, increasing buffer size and reducing file system footprint by going to FS_TINY results in a smaller memory footprint.

- Increased the audio buffer from 512 to 1024 bytes. Together with the changes above, this means the audio buffer can handle up to 128 ms of delays.

While making these changes, I discovered that there is a significant delay every 128 kB when writing to the microSD card. This corresponds with the change from one erase block to the next. What happens is that a write operation crosses the block boundary, which triggers an erase of the next block. Although the f_write function returns quickly, in reality the microSD card's processor is still working away on the erase. If the write is followed closely by a read, then the read experiences a delay of up to 80 ms. The increased audio buffer size is sufficient to handle this worst case scenario.