FLAC picture blocks have `u32::MAX` possible picture types, but only 20 are actually defined. In the [spec] it states, "Others are reserved and should not be used."
We used to only allow a picture type of up to 255 to be in sync with ID3v2's APIC, where this model comes from. Now any picture type can be specified and it will just be clamped to 255, so long as `ParsingMode::Strict` is not being used.
When a custom sample rate (or multiplier) was encountered, it would accidentally be overwritten with 0, causing incorrect duration and bitrate values.
This was due to us reading the metadata sub blocks first (when necessary) and then immediately overwriting the sample rate with the value from the block header (which is 0 in the presence of a custom sample rate).
This is not allowed [by spec](https://xiph.org/flac/format.html#def_VORBIS_COMMENT), but is still possible to encounter in the wild. Now we will just tag whichever tag happens to be latest in the stream and use it, they **will not be merged** like other formats (such as ID3v2 in MP3) where multiple tags are valid.
Now, when inserting an atom that already exists in a tag, the data is taken from the provided atom and merged with the existing value in the tag. This should ensure that the value that already exists in the tag will remain the dominant one.
Previously, `Ilst::insert_picture` would insert a new `covr` atom, and `Ilst::pictures` would check for multiple `covr` atoms. Now, when inserting pictures they will all be merged into a single atom.
Additionally, `Ilst::insert` will check for `covr` atom inserts, and perform `Ilst::insert_picture` correctly.
The spec defines multiple frames that are only meant to appear in a tag once. They are the following: "MCDI", "ETCO", "MLLT", "SYTC", "RVRB", "PCNT", "RBUF", "POSS", "OWNE", "SEEK", and "ASPI".
We now check for their presence in `Id3v2::insert` to prevent multiple appearing in a tag.
