Lightweight catalog implementation via extensions

This proposal is an early response to the proposed DEPR of course-discovery.

Specifically from this comment, the new catalog app:

new catalog app: should this proposal take off, I believe we should put the core primitives like programs or catalog and write the most basic implementation possible. Then leave every bit of product development to plugins. I don't think that requirements for courses or anything so specific should be implemented in core. Mostly a models and calls to extension points should live there.

Roughly, when looking at the bare minimum requirements, out team looked at our current projects and the existing implementations of the same or very similar features in:

With this in mind, we are proposing a bare implementation that includes only:

FlexibleCatalogModel
    course_runs: as manyToMany to CourseOverview
    query_string: a string to match course_runs dinamically
    slug: url friendly
    name: for humans
    get_course_runs: the method that either does fetches the course_runs
                     directly or that uses the query string for the dynamic
                     asignment. Implemented through filters so that

    search: a method that does flexible search. This would be implemented via
            filters so that the default implementation can be swapped. I would
            also vouch for shipping with a mysql only implementation and one with
            meilisearch

    model specific openedx-filters: before meaningful changes are made
    model specific openedx-events: after the catalog changes in a meaningful way


API REST:
    CRUD on the FlexibleCatalog
        the API must allow to set the course_runs or the query
        the API to list the catalogs should use get_course_runs so that filters are respected
    Search API that uses the search method so that filters are respected

Python API
    get_catalogs: a public api method that includes filters to do access control
    get_course_runs: for a catalog without exposing the model (for stability for those that can manage to only use this)
    exposing the search api
    CRUD on the Catalog

Naturally including the accompanying:
- docs
- serializers
- forms
- admin pages
- QA suite
- …