Implement compressed audio recording and import

[Lingomat]

In order to share work directly from Aikuma, the audio will need to be compressed. This forked recorder.js is active and supports recording directly to ogg opus.
https://github.com/chris-rudmin/Recorderjs

I'm happy to accept ogg opus as our preferred format. The best performance going, broad standards support as an official web standard (thanks to no patent nonsense) and there are performant client-side encoder libraries.

If the user has imported an mp3 or M4A file, we don't need to (shouldn't) do anything, but it's probably better to encode a wav immediately.

Steps:

1. Record New: Replace /mattdiamond/Recorderjs with /chris-rudmin/Recorderjs
2. Insert basic options into settings view (bitrate)
3. Implement a wav -> Opus compression (/Rillke/opusenc.js)
4. Support having more than one source file where one is an archive, the other compressed.

Note: I tried the opus compression on my laptop and it encoded at 25X real-time. It's likely to be 10X on a mainstream device. Acceptable.

[Lingomat]

Our data backend seems presently hard wired for wav. This will first need to be resolved to accept and properly record the file types for ogg and mp3.

There are good microphone libraries that handle compression but we also want (I think) the ability to compress imported audio. Compression libraries are basically cross-compiled from C and are very large, comparatively. I'm minded to consider if we can use a single one rather than two different ones for microphone and file import.

[Lingomat]

The new MediaRecorder API gives us the ability to save directly to Ogg Opus, an excellent codec. This removes the need to use an external library based on a port of large C++ compression libraries.

However Chrome currently doesn't support Opus via WebAudio [1] so we're putting this on the backburner until it's fixed.

I still think we need a mechanism to compress large imported wav files. This may need a library to do it since the MediaRecorder API doesn't look like it will support external sources of data. Again, I have a preference for supporting Ogg Opus for this and so that issue too will need to be on the backburner until the WebAudio issue is resolved by the Chrome developers.

Actually, it seems compressed audio doesn't give us anything but increased load times. I'm minded to abandon this idea completely.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=482934