Removed ProtocolInfo from MediaResource and fixed transferMode.dlna.org response header

After encountering another issue with using the ProtocolInfo class in
 MediaResource (the ProtocolInfos for the playlists in the MediaContainer
 object seem to be getting mutated by the didl-lite serialization, in this
 case), decided to simplify matters and have MediaResource be a flat container
 for both the res block and protocolInfo fields. This resolves the issues
 we were seeing and allows more straight-forward usage of the object.
 (e.g we no longer need to set protocol to "http-get" all over the place to
 prevent ProtocolInfo from complaining)

During testing with playlists, found a bug in HTTPGetHandler.
 add_response_headers(). It was always setting the transfer mode response
 header to "Streaming". This isn't correct for non-AV resources. Changed it
 to respond with whatever (the already-added) get_default_transfer_mode() returns.

Changed ODIDMediaEngine.set_resource_field() to use a switch instead of
 nested if/elses.

Fixed up any formatting I ran into during edits.

Ran tests with (multiple) local CDS browse/search.
Streamed media and playlists with MediaExport+Simple/GstMediaEngine.
Streamed a couple transcoded resources.
Examined HTTP response headers for correctness.