Merge of the retrofit branch - re-enabling Tracker, MediaExport, simple/gstMediaEngines

This merge includes changes to librygel-server and dependencies that
 enable both the device-source content model that the ODID
 MediaServer/MediaEngine uses and the user-sourced content model that
 the Tracker and MediaExport MediaServers use.

Details are below. But in broad strokes, the MediaItem hierarchy
 is changed to introduce a more abstract base item class that
 doesn't presume locally-served items are in locally-accessible
 files and/or that all item/resource metadata derives from the
 locally-accessible file. The MediaFileItem subclass models user-
 supplied single-file content with MediaItem being the abstract
 base that non-file-based/device-sourced can derive from.

To support this are changes to the MediaEngine API to enable its
 use for both device-source and user-sourced content. And the
 HTTP request processing has been changed to remove MediaItem
 assumptions and incorporate more delegation to type-specific
 HTTP request handlers.

Details:

MediaExport, Tracker, and ODID MediaServers are updated to use
 the new MediaObject model described above.

TransformationManager and Transformations are no more. Since the
 MediaEngine can provide multiple resources via
 get_resources_for_item(), MEs that support transformations can
 do so via this method. GstMediaEngine is retrofitted to use this
 mechanism.

The way that a MediaItem is serialized is changed now that the
 MediaObject has a MediaResource list and that the MediaServer
 has latitude to preload the resource list. To support the
 "shadow" resources that MediaFileItem subclasses provide
 (thumbnails, subtitles, and album art), MFI will call a
 method to allow subclasses to augment the MO resource list
 prior to serialization. The functionality previously
 implemented via add_resources/add_proxy_resources/add_resource
 is refactored to add non-res-block values in serialize()
 over-rides and add_resources() to add thumbnails.

Changes to the HTTPGetHandler contract - and removal of the
 identity and transformation handlers - allowed for large
 simplifications and better DLNA compliance in the HTTP
 processing code related to transfer mode. (additions to
 HTTPGetHandler include default/supported transfer mode,
 resource size/duration, and time-seek support query).

Thumbnail and subtitle handling is now done via their own
 HTTPGetHandlers instead of having special-case logic within the
 HTTPIdentityHandler (which no longer exists). This simplifies
 the HTTP processing code in a number of places.

HTTPItemURI is simplified as a side-effect of removal of the
 additional handlers. It no longer needs to perform type-
 specific checks on the resolved MediaItem. This is now delegated
 the the type-specific HTTPGetHandler.

MediaContainer playlists (didl_s and m3u) are now modeled
 as MediaResources. This allowed the HTTPPlaylistHandler to be
 removed along with other special-case logic.

Resource protocolInfo values which are specific to the HTTPServer
 are now set via the HTTPServer (e.g. supported transfer modes,
 protocol, stalling)

MediaResource no longer uses a ProtocolInfo. The fields are
 incorporated into MediaResource as was done previously for
 DIDLLiteResource. There were too many issues/side-effects in
 their current forms.

All three MediaServers and all three MediaEngines tested to
 varying degrees.

Some CTT testing performed.

Performed local and remote browse/search tests with upnp universal
 and av control points.

Ran various http byte/time-seek range request scenarios.

Performed didl-s and m3u playlist tests.

Performed a few video stream transformation tests.

No regressions observed. But more testing is certainly required
 with 3rd-party endpoints and various content forms - esp thumbnails,
 album art, and subtitles.