add EXT-X-DATERANGE support (as alternative for SCTE35 tags);

[vany-egorov]

see https://tools.ietf.org/html/draft-pantos-http-live-streaming-21#section-4.3.2.7.1 see http://devstreaming.apple.com/videos/wwdc/2016/504m956dgg4hlw2uez9/504/504_whats_new_in_http_live_streaming.pdf

iOS devices support EXT-X-DATERANGE for AD splicing;

[coveralls]

Coverage decreased (-3.3%) to 64.144% when pulling 1a91bd237f4d683afd917ed5cd98afb9ec0b653e on BradburyLab:master into af670bc2dfd4a58784fce4ad2356a020578e107f on grafov:master.

[bradleyfalzon]

I'm happy to review this, but can I have a couple days, I want to look more closely at the spec and the implementation. A very quick review it looks good to me, but I'd like to understand why test coverage decreased and if it's possible to have matching reader support?

Related #81

[coveralls]

Coverage decreased (-2.2%) to 65.191% when pulling 8740be63337bc1d5e38e32cd149a1618a6ed7893 on BradburyLab:master into af670bc2dfd4a58784fce4ad2356a020578e107f on grafov:master.

[vany-egorov]

Reader support added.

[bradleyfalzon]

A part from the additional line removal, I don't think using a [][2]string is the best way to handle this new type in this library.

We lose a lot of safety by using slices like this, it requires the client to format (and quote) the values correctly when it shouldn't be their responsibility, and it doesn't match our current convention with Key, Map and existing SCTE support.

I think we're better to have a dedicated type for DateRange, something like:

type DateRange struct {
        ID              string
        Class           string
        StartDate       time.Time
        EndDate         time.Time
        Duration        time.Duration
        PlannedDuration time.Duration
        SCTE35Command   string
        SCTE35In        string
        SCTE35Out       string
        EndOnNext       string
        X map[string]string   // X-<client-attribute> TBD 
}

As for the X types, I actually think we should have another type, such as:

type Attribute struct {
    Key string
    value interface{}
}

// Value returns the attribute's value
func (a *Attribute) Value() interface{} {
    return a.value
}

// decimal-floating-point
func (a *Attribute) SetFloat(value float64) {
    a.value = value
}

// quoted-string
func (a *Attribute) SetString(value string) {
    a.value = value
}

// hexadecimal-sequence
func (a *Attribute) SetHex(value string) {
    a.value = value
}

// etc https://tools.ietf.org/html/draft-pantos-http-live-streaming-22#section-4.3.2.7

Perhaps having another type to switch on such as type AttributeValueType int, that is set in each Set* method, so the writer knows how to format correctly. I haven't put a lot of thought on this method, so happy to hear your and @grafov's thoughts - and perhaps testing out an API to see how it feels.

It would then be nice if we could reuse this Attribute type to support unknown attributes elsewhere, as we currently lose that detail when reading (and then writing) - this relates to #82.

EDIT: I originally suggested the type [][2]string for X field in the DateRange type, but I think we could achieve a better result with map[string]string - similar to how https://golang.org/pkg/net/url/#Values is implemented.