Added support for the Range request header and Content-Range response in...

... HTTP HEAD request.  This is needed for non-dlna servers to get additional info about byte ranges available.  Also added the time_seek_response_received to indicate if the server responded to the timeseekrange header and if time ranges are available.  Added an option when issuing the head request to not include the range header.  At least one server (OCAP RI DMS), will not include the timeseekrange header in the HEAD response if the Range header was included in the request.  Need the ability to get info from timeseekrange header in response so added logic to re-issue HEAD request without range header if server claims to support time seeking but did not include the timeseekrange header in initial HEAD request.  Include time_seek_response_received as an additional parameter when verifying the validity of seeks so we know we are comparing against valid range values.  Added HTTP status code 206 to list of acceptable non-error return values.  Got rid of the space between the HTTP request header identifier and the ":" since the Golden DMS did not like it and upon further spec review, appears to be the way it is spec'd to be.  Moved the logic to parse byte ranges from time seek range method to new method - dlna_src_head_response_parse_byte_range.  This is now used when parsing timeseekrange and also ContentRange response header.  It will also be used for dtcp header parsing.  Clean up the print out HEAD response to not include the time seek range fields if that header was not included in the response.  I plan to do the same thing with DTCP headers.