File-output drivers

I propose the implementation of one or more file-output drivers for libsoundio.

Currently, there is no facility to direct audio samples [that would have gone to a sound device] to a file instead. This is a useful mechanism for testing/debugging and for supporting systems without a sound device, without the loss of sound data inherent to the existing dummy driver.

(In fact, [LibAO](https://xiph.org/ao/doc/ao_open_file.html) and [PortAudio](http://portaudio.com/docs/v19-doxydocs-dev/write__wav_8h_source.html) have this functionality already. I can certainly vouch for its value in the former.)

The file that is created by this driver can take one of three formats that I can see: headerless raw samples, AU, and WAV. Each of these has pros and cons:

| | Pros | Cons |
| --- | --- | --- |
| RAW | Easy to implement, low overhead, does not require seekable stream | No internal metadata, not loadable by novice sound applications, error-prone when loading is supported |
| AU | Easy to implement, metadata is included, does not require seekable stream | Not a popular format, dubious support among sound applications, small byte-swap overhead on little-endian systems |
| WAV | Metadata is included, loadable by basically anything and everything | Somewhat more complex writer, requires seekable stream (so no output to e.g. stdout), 4GB maximum file size |

Given the tradeoffs, I think the ranking of most- to least-desirable is WAV, RAW, AU. The RAW driver is likely to arise in the course of implementing WAV, and AU borders on trivial, so if I can do WAV I can do all three.

Note: The WAV/AU writer would be implemented standalone, without the use of a sound-file library. This facility is not intended to be an alternative to libavformat/libsndfile/libaudiofile et al.; support for sound-file features like compression, codecs, lossy encoding, etc. is out of scope. This is just about getting the samples to disk in a usable form.

(Conceivably, this could be extended in the future to support file-input, simulating audio capture with the content of a sound file. But this is not the itch I'm looking to scratch.)

The only parameter that should be needed by these drivers beyond those of existing drivers is the file path/stream for the output.