ID3: Consider size of extended header when reading ID3 data

[phw]

Reading of ID3 tags with extended headers could fail, as the data being read did not consider that the extended header had already been read. This meant it would read more data then actually part of the ID3 tags, and if not enough data was available (e.g. the ID3 is located at the end of the file) it would fail.

Fixes #630

[phw]

@lazka maybe it should be discussed if there is any value in mutagen supporting the extended header, maybe at least in a way that it tries to preserve it, at least those flags that make sense. Currently upon saving the extended header will be gone as it is not supported.

But this PR is purely for fixing the loading of such files, as at least this part is implemented, but was not fully working.

[lazka]

@lazka maybe it should be discussed if there is any value in mutagen supporting the extended header, maybe at least in a way that it tries to preserve it, at least those flags that make sense. Currently upon saving the extended header will be gone as it is not supported.

Hm, I wouldn't try to preserve them, since they have to be kept in sync with the data and we can't just start failing on save when writing a new tag, but we could expose them on load and allow them as extra save options.

• Tag is an update: This could be exposed and we could allow the user to set it. I don't know any software supporting this though.
• CRC data present: We could allow expose it, and allow to write it. But it would make every write slower since we have to read back everything. Also we would need to expose the extended header size as well, so it can be checked by the user.
• Tag restrictions: Could be a save option which makes sure all frames respect the restrictions.. but not sure there are any use cases for that.

But, I'm not sure that this is all worth it. We should at least document somewhere which parts of the spec we implement and which we don't, like footers for example.