Improve `icekit.page_types.article`.

[mrmachine]

This is currently a concrete implementation of the icekit.content_collections pattern. But it needs some improvement:

• [ ] Move the Article to icekit.articles and make it polymorphic, so that we can bundle article variations (essay, short form, long form, image/video/text, etc.) to be listed along side each other, and allow projects to implement their own article plugins (if needed). Bundled sub-types should go in icekit.articles.plugins.* packages (or project codebase). Maybe even break this out to a separate icekit-articles repo, similar to icekit-events, as it is providing a non-page polymorphic parent model, and it will be the core "story telling engine" which is an equally big/important feature as events.
• [ ] Refactor ArticleCategoryPage page as ArticleListPage, and have it list all polymorphic articles by default and provide filtering by sub-type.
• [ ] Add ArticleListPage.allowed_types = ModelMultipleChoiceField(...) (pointing at ContentType, limited to Article subtypes), so we can add list pages just for one or a subset of article subtypes.
• [ ] Make Article.parent optional with blank=True, null=True and add a boolean ArticleListPage.allow_parent_links field which exposes a list page as a target for Article.parent FKs and filters the queryset of articles to be listed. Perhaps we make this a required field in forms at runtime based on project settings and article sub-type, if there's a need for it to be a required field in some cases. But we shouldn't require that all article sub-types always specify a parent. Maybe if it's not required, it doesn't show up in the form at all.
• [ ] Add Article.metadata = JSONField(...) to store arbitrary and client/project specific content metadata. We will need a custom admin widget which is configurable via settings. E.g. to specify that icekit.articles.plugins.foo metadata has a released (datetime) field and a genre (choice field) field, etc. This should allow us to store any slight content variations for specific projects without having to fork the articles app or create nearly identical project specific article sub-types in every project.

@cogat @jmurty thoughts?

[cogat]

NB it should also implement Django's MultipleObjectMixin for consistency.