Added parsing and writing for BOM (Byte Order Mark) characters.

[Wopple]

Issue: #18

• parser gracefully ignores a leading BOM
• added a builder for the PlaylistWriter
• BOM writing is supported through the deprecated method PlaylistWriter.Builder.useByteOrderMark()

It is deprecated because of this bit from the specification:

Playlist files MUST be encoded in UTF-8 [RFC3629].  They MUST NOT
contain any byte order mark (BOM); Clients SHOULD reject Playlists
which contain a BOM or do not parse as UTF-8.

@derjust

[derjust]

I like all of the implementation itself except for the way how it is exposed to the client/API:

• In a way I think we should be able to read the stuff we are writing but that might be arguably implemented in a second PR.
• But having reading in mind, ParsingMode pops to my mind. Whereas a simple enum might be not sufficient anymore I definitely prefer that over a dedicated method read/writeWithBom. Mostly because the next writeWithUnicorn is around the corner. \ So getting back to ParsingMode (which is now a bad name) something like that I would imagine:

ProcessingMode pm = new ProcessingMode.Builder()
    .withBom(true)
    .withUnknownTags(false);

Having HLS-land still be more of a wild-west territory I feel that this is more future proof and aligns with what is already there.

But I absolutely acknowledge that there are alot of "I" in this comment so there is little to backup my position ;-)

[Wopple]

My reason for a differently named method is because I wanted it to be clear why it was deprecated. However, with your suggested builder approach, we could deprecate only the useBom() method in the builder which would be more clear. I will make that change.

We can read the playlists with a BOM. I even wrote a test for that. If a BOM is detected at the start of the stream, it is removed and ignored. The BOM has nothing to do with the actual playlist so it should not affect the output.

We may have to change this code around a little bit when we want to support writing multiple playlists delimited by ENDLIST tags.

[derjust]

+1 Maybe creating an issue for the bom/endlist situation.