Made a change to the offsets_covering_time_range() function to tighten the time range

When the start or end of a time range included the exact value in the index
 file, offsets_covering_time_range() would use the range starting one entry
 before/after (respectively) the target time.

While the results returned from a TimeSeekRange response that spans the
 requested range is legal, it's non ideal. And it causes CTT test 7.4.35.1
 to fail (which it shouldn't, according to DLNA part 1 7.5.4.3.2.24.4 +
 7.5.4.3.2.24.7)

This change adjusts the logic so that start/end times that exactly match
 index entries time-wise will return a range starting with the matched entry/
 entries times.

Tested with TimeSeeekRange npt values starting with exact index entry times,
 inter-entry times, and open ranges with forward- and reverse-rate values.
Fix for CVP2RI-403: Access violation performing time-seek of B-AVC_MP4_MP_SD-08.MP4

    This bug uncovered a problem related to access of non-local variables
     in a vala closure. Via a number of experiments, it appears that access
     to member variables - including "this" - is not safe from a closure within
     a closure, as ODIDDataSource.start_mp4_container_source() was using.

    To remedy, the logic previously contained within the anonymous BufferReady
     delegate to the MP4 BufferGeneratingOutputStream is now relocated to
     ODIDDataSource.on_mp4_data_ready(). And while this implementation still
     uses anonymous functions to invoke the data_available() notifications on
     the glib main thread, on_mp4_data_ready() ready performs the DTCP
     encryption in the function body instead of the anonymous invocation
     (this was just recently added - see CVP2RI-406).

    The ODIDDataSource has a "stopped" state variable to help prevent spurious
     invocation of data_available() after DataSource.stop().

    Additionally, I determined that having the MP4 BufferGeneratingOutputStream
     stop() and close() methods invoke BufferReady when a partial buffer is
     waiting for delivery didn't make sense. The OutputDataStream.close()
     semantics don't imply this (as it does for flush()). (a) stop() should
     operate similar to close() (from the consumer end), and (b) if a caller
     calls stop(), they're clearly not interested in data. So it fails both
     the contract and common-sense tests. Implementation and documentation of
     stop() updated accordingly. And the flush_partial_buffer memvar needed
     to be set to "true" to allow the last buffer fragment to be flushed.

    Performed a large number of tests with a test script with reliable
     reproduced the issue described in CVP2RI-403 with and without DTCP enabled.
     The Access Violation went from 50% reproduction to 0%. (the test script is
     attached to CVP2RI-403)

    Tested with the curl-abort-transfer.sh GET abort test (x100) and
     some misc TimeSeekRange ranges with B-AVC_MP4_MP_SD-08.MP4 that
     reproduced the issue seen in MCVT testing. The issue didn't reproduce.