Content Plugin Refactoring

This is an attempt to simplify the content plugin models a bit, had some trouble tracing down how everything fits together and saw some opportunity to trim down a little.

Dropped the ContentSet and EntCertContentSet, these are basically just two layers of wrapper around a list. I suspect the goal was to not let plugins use slicing or indicies so we could someday pass a set instead. However we can use a set internally when that time comes and convert to a list when we pass through, should that ever become necessary (or switch to a set now). All calling code just uses iterators which should be fine with both regardless, but it seems ok to me to commit to passing a list here.

Moved code to find content by type to the entitlement source so it can be reused in other content plugins, all of which would likely need it. This allows us to drop the entire OsTreeContents object as well, as that is basically just a list once the find by type code is moved.

Corrected a test that was passing the wrong type of content object, issue being hidden because it was a mock.

Refactor to try and cleanup the ambiguity around EntCertEntitledContent, specifically remove it's reference to another content object which we're trying to hide here (preventing callers doing things like "content.content"), and instead copy the fields we intend to expose.

More details in individual commits.
I'm not sure how much the plugins need to be able to extend the process of finding Content's from entitlements. If we can let the main app be responsible for generating a set of Contents, we can drop EntitlementSource (and basically provide a ContentSource or just a list of Contents). 

main app would gather the contents, and do any filtering (content_type, tags? arch? uniqueness?)  and the
content plugin basically just renders those.

It may make sense to split the current content plugin into two or more plugin hooks. One basically the content "render", and the other setting up (or modifying) something like EntitlementSource. Plugins not based on current ent certs (a consumer id driven content api, ala RHN?) could genate/render content directly.