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 don't think we should go for two separate plugin hooks, if a plugin wants to bypass the entitlement source, it can do that internally. I can't see any reason to force it to use our concept of entitlement source, set one up, pass it back, so we can pass it back in again. Really hoping to make this simpler and that feels like the opposite direction.

Likewise if a plugin wants finer grained control over filtering content down, it can do that internally, it is not required to use find_by_type.

Should we do a more generic find(content_type="docker") method on the entitlement source instead so we can filter on other generic'ish things in the future without separate methods for them? I think I like the sound of that better.