The dashboard must be able to sort shows.

In aa7e7f41 filters were renamed
to a camelCase scheme. This is actually wrong, because the filter
names are already transformed to snake_case when the are applied
to the FilterSet.

The nested timeslot routes allowed us to filter the timeslots by show
and schedule. We’ve deprecated nested endpoints with the alpha.2
release, but still need the actual filtering logic.

To be honest I'm not sure this is the right way to do it.

This is mainly so we can start phasing out nested routes.
With nested routes objects were filtered based on route parameters.
Therefore we need something similar in the form of query parameters.

Fixes: #133

If a collection is filtered by an invalid id (meaning the model the
query argument points to with that specific id does not exist), we no
longer return an error. Instead the filter is applied without a lookup.

Fixes #104

This adds extensive API documentation based on the official API
documentation [1] and conflict resolution [2] documents.

Where possible field documentation was added to models or serializers,
so that other code like auto-generated forms can also profit from these
changes (hence the migration part of this commit).

The changes introduce two new API endpoints.

`/api/v1/schema/` exposes the API schema as an OpenAPI 3.0.3 document.
The standard format is yaml but can be switched to JSON by appending the
`?format=json` query parameter.

`/api/v1/schema/swagger-ui/` renders a visual representation of the
OpenAPI 3 specification with support for testing the individual API
endpoints including authentication.

[1]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/api-definition.md
[2]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/conflict-resolution.md

In addition to the

	?foo=1,2,3

filter syntax we now also support

	?foo=1&foo=2&foo=3
	?foo[]=1&foo[]=2&foo[]=3

The filter defaults caused the queryset to always yield results filtered
for the coming 60 days. We should only apply filter defaults when
listing timeslots, not when querying individual items.

This adds extensive API documentation based on the official API
documentation [1] and conflict resolution [2] documents.

Where possible field documentation was added to models or serializers,
so that other code like auto-generated forms can also profit from these
changes (hence the migration part of this commit).

The changes introduce two new API endpoints.

`/api/v1/schema/` exposes the API schema as an OpenAPI 3.0.3 document.
The standard format is yaml but can be switched to JSON by appending the
`?format=json` query parameter.

`/api/v1/schema/swagger-ui/` renders a visual representation of the
OpenAPI 3 specification with support for testing the individual API
endpoints including authentication.

[1]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/api-definition.md
[2]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/conflict-resolution.md

In addition to the

	?foo=1,2,3

filter syntax we now also support

	?foo=1&foo=2&foo=3
	?foo[]=1&foo[]=2&foo[]=3

The filter defaults caused the queryset to always yield results filtered
for the coming 60 days. We should only apply filter defaults when
listing timeslots, not when querying individual items.

This change re-implements all existing collection filters for the
APINoteViewSet with a FilterSet. No breaking changes are expected.

APICategoryViewSet, APITypeViewSet, APITopicViewSet,
APIMusicFocusViewSet, APIFundingCategoryViewSet, APILanguageViewSet, and
APIHostViewSet all used the same base class implementing get_queryset
for filtering by their active state. This is now handled by a generic
FilterSet.

This change re-implements all existing collection filters for the
APITimeSlotViewSet with a FilterSet. No breaking changes are expected,
though there are some changes in semantics:

* The start and end query parameters no longer need to be specified
  together. If users only want to modify the start or end date they
  can now do that.
  If start is specified and end is not, end will be start + 60 days.
* If end was not set it would default to start + 60 days at 00:00.
  This is now fixed and end will be start + 60 days at 23:59:59.
* end now uses time.max, which selects the latest possible time on
  the specified date.
* The surrounding-filter now accepts a datetime value and will be set
  to the current time if only the query parameter but no value
  has been set.
* All filters are now applied in series. This wasn’t the case for
  every filter, e.g. the surrounding-filter would return early.

This change re-implements all existing collection filters for the
APIShowViewSet with a FilterSet. No breaking changes are expected,
though there are some changes in semantics:

* The owner, host, musicfocus, language, category, and topic
  filters now accept multiple values (i.e. ?category=2,3)
* The owner, host, musicfocus, language, category, topic, and type
  filter values are now validated and may be rejected as invalid if
  the referenced object does not exist.