Bug 841949 - Improve id3 parsing in the music app

r? @davidflanagan

I've split this PR up into discrete chunks (add a test, then add the feature that I'm testing in the next commit) to hopefully make it easier to test everything, or at least to see what it is that I'm doing. When this gets r+, I'll collapse them all into one commit.

First, I added tests for our existing id3 parsing. Then I tested and fixed an issue with our extended header support. I'm pretty sure this is correct now, since it's what the spec says and other parsers do it, though I think extended headers are extremely rare in practice.

Next, I wrote tests for unsynchronization and then implemented it. I think I got this right, and it works on the real-world examples of unsynchronization that I have.

Finally, I tested and added support for multi-value frames in id3v2.4. This should all be correct, except that I'm not 100% sure that there'll only be one BOM for the whole frame under UTF-16. I couldn't find any real world examples of this, since all the id3v2.4 stuff I've seen uses UTF-8.

If you'd like to understand the test mp3s I made, go over to https://github.com/jimporter/id3gen, which contains all the code I use to generate the test files.

https://bugzilla.mozilla.org/show_bug.cgi?id=841949
This does not look right. If some file in the middle of the enumeration needs to be reparsed we'll end up calling the callback prematurely.

Shouldn't it be like this:

```
if (fileinfo !== null) {
  if (!fileinfo.needsReparse) {
    batch.push(fileinfo);
  }
}
else { 
  callback(batch);
}
```