Enhance M3U UTF-8 encoding support

[tkem]

As observed by @Joolee in #1364, there are several issues with the M3U backend's current (lack of) UTF-8 encoding support:

• Though UTF-8 is supported when reading .m3u8 files, M3UPlaylistsProvider.save() will always use Latin-1 encoding.
• Some clients use the .m3u extension and a BOM when saving M3U playlists in UTF-8 encoding. If these are to be supported, the BOM should probably also be written when editing and saving such playlists.

Generally speaking, the M3U backend badly needs some love, and also a major refactoring IMHO.

[tkem]

Note that @Joolee's patch uses the external chardet module, which is not used by Mopidy yet. Whether we want to introduce an additional dependency remains TBD. This wouldn't be much of an issue if the M3U backend was split from Mopidy core, as already planned, and made a separate extension.

[jodal]

I'd prefer to not add any deps as long as it is part of Mopidy core.

[adamcik]

Then BOM check can probably be done just fine without the extra chardet module, as we only need that if we want to guess what the rest of the file is. An other option could also just be to have a list of encodings to fallback to. But at the same time I'd rather kill our playlist parsing in favor of the totem libs.

[tkem]

@adamcik: Parsing is just "half" part of the API - do the totem libs also support writing playlists? @jodal: Me too, so as a first step I consider making the encoding for *.m3u configurable, with default latin1 but can be set to utf-8-sig by the user.

[kingosticks]

https://developer.gnome.org/totem-pl-parser/3.10/TotemPlParser.html#totem-pl-parser-save Looks like it supports writing and manipulation too.

[tkem]

@kingosticks: Thanks! However, since totem-pl supports several playlist formats, I'm wondering whether this shouldn't become a separate backend.