Fix MP4 genre parsing: prefer ©gen text over gnre binary

[aw-was-here]

This patch fixes MP4 genre parsing to follow the MP4 specification recommendation by preferring text genre (©gen) over binary genre (gnre) when both are present. This resolves discrepancies with other media players.

Implementation:

• Store ©gen and gnre values in separate internal fields during parsing
• Apply priority logic after atom traversal (order-independent parsing)
• Clean up internal fields before returning to user
• Add _cleanup_internal_fields() infrastructure for internal field management

The priority logic ensures consistent genre reporting regardless of the order atoms appear in the file, matching behavior of major media players.

(includes #262 as a pre-req)

fixes #261

[mathiascode]

I would prefer this approach, to avoid polluting the base TinyTag class:

• Have a list variable in the _MP4 class, e.g. self._id3v1_genres
• Use a custom field name for ID3v1 genres only, e.g. id3v1_genre, which is used inside _parse_id3v1_genre()
• In the section where fields are set in _traverse_atoms(), add a special case for the id3v1_genre field name, and append the value to self._id3v1_genres
• Once all atoms are traversed, check if self.genre was set. If not, call self._set_field("genre", value) for all values in self._id3v1_genres.

I don't know if there are files out there with multiple genres, but better safe than sorry.

[mathiascode]

Thinking about this some more, do you have files where tinytag gives a different result than other tag readers? I tried your test sample file with a few applications (VLC, Kid3 and Picard), and they don't seem to prioritize specific genre atom types. They either pick the first one, or show all of them in the order they were read (same as tinytag).