Added support for live streaming of odid media items (merge of cablelabs/live-streaming)

The ODIDMediaEngine now supports the streaming of on-disk resources.

 New rygel.conf ODIDMediaEngine variables allow for control of live serving
 of on-disk resources:

  live-sim-start-mode: "on-demand" or "manual". Will cause the MediaEngine
                       start the live simulator associated with a resource
                       at the point of first access or via the control port.
                       Default is "on-demand".

  live-sim-autoreset-time: The time (in seconds) after last resource access
                           which the live simulator associated with a resource
                           will be automatically reset. Default is 60 seconds.

 Individual resources have their own control variables (via resource.info):

  live: "true" or "false". Signals that the resource is going to be presented
        in live mode. Default is false.

  live-time-window: Size of the time window, in seconds (only applies when
                    live=true). If not present, there's no buffering limit
                    (e.g. emulating in-progress recording). If 0, there's no
                    buffering (strictly live with no random access)

  live-start-offset: Amount of time to adjust the start by, in seconds
                     (only applies when live=true). e.g. Setting this to "60"
                     simulates content having started 60 seconds prior to the
                     first content access. Default is 0 seconds.

  limited-operation-mode: The DLNA limited operation mode (0 or 1) (only applies
                          when live=true and live-time-window is >0).
                          Default is 0.

 The ODIDMediaEngine will enforce the content limits controlled by these
  variables and will setup the ProtocolInfo ORG_OP, flags, and res block
  variables appropriate to the mode. And the availableSeekRange.dlna.org
  response header will be returned appropriately (when live-time-window > 0).

 If/when the DMR reads data at the live point, the DMR reads will be paced as
  the content is made available. And when live mode terminates, the CDS item
  will be updated with a res block/ProtocolInfo that represents the available
  content. e.g. Any buffered content will be available in full random access.

A few changes were required to librygel-server to support live resources.

 DLNAAvailableSeekRangeRequest/DLNAAvailableSeekRangeResponse classes are added.

 MediaObject.create_data_source_for_resource() is now allowed to throw an
  error - so that the errors that can occur when setting up live mode can be
  propagated.

 The HTTPMediaResourceHandler now considers byte seek supported on a resource
  if either full random access is supported (ORG_OP b-val is 1) or limited
  byte seek is supported (via the protocolInfo flag).

 The HTTPByteSeekRequest class had to get an overhaul. It couldn't
  handle open byte ranges with unknown content lengths due to leveraging
  the libsoup message header get_ranges() function. This attempts to turn
  an open range request into a closed request. And it's not really conformant
  with DLNA 7.5.4.3.2.22.3 regardless. This class is now DLNA 7.5.4.3.2.22.3-
  conformant.

 Similarly, the Rygel DataSink class was assuming that a HTTPByteSeekRequest
  could always have a known content length. Added a check there to only
  set the max_bytes on the sink if/when the range_length was defined.

 HTTPTimeSeekResponse wasn't prepared to receive an open-range byte response
  (a response without an end time) and was calculating its range_length value
  incorrectly. range_length will now be UNSPECIFIED in this case. Accordingly,
  it now won't set the content length in add_response_headers() and it won't
  include the "bytes=" field in the response (DLNA 7.5.4.3.2.24.3 doesn't allow
  an open byte range in the response form of this header)

Ran a variety of tests in each mode with various ad-hoc tests and with a few
 clients. None have supported limited random access. But streaming at the live
 point has been working reliably.

DLNA CTT/LPTT tests were run with live mode disabled (the tests don't currently
 support live). A couple regressions were found and fixed and all tests are
 passing.