The login dialog header and the page header of the steering admin
interface are confusing because the naming and URLs don’t match up with
user expectations.

This adds sensible defaults and allows administrators to customize the
values for their specific needs.

The /program/calender endpoint returns an envelope object that returns
related objects for the query.

Without the fix drf-spectacular would advertise the response type as an
array of CalendarSchema even though it is just the CalenderSchema.

drf-spectacular is smart and checks the type of the value attribute for
filters with a method override.

If we don’t provide a type hint it uses the default type hint it derives
for the field, which is what we want in this case.

The update logic of the repetition_of field did not consider cases in
which the episode field of TimeSlot objects is deleted.

This fix populates the TimeSlot’s repetition_of_id field with a subquery
instead of using a separate database field for it.

The decision to keep repetition_of as a separate database field was made
on the assumption that this would be a performance problem. However, the
subquery for the repetition_of field is quite performant, especially
with a separate database index. In contrast, the update logic for a
materialized repetition_of field is quite complex and it is easy to miss
cases that should have updated the field.

As long as we don’t have an actual use case in which retrieving
timeslots becomes slow because of this subquery, we should refrain from
materializing the field.

This change makes the notes independent of timeslots and renames them to
episodes.

Multiple timeslots can now refer to the same episode introducing a new
and more convenient model for repetitions that does not duplicate
content.

This change also makes it possible for users to pre-plan their episodes
without the need for radio planners to create a timeslot for the episode
first.

refs #249
refs aura#382

This is helpful for writing migration tests.

There currently isn’t a use-case for handling notes and playlists in
schedule conflicts and the dashboard doesn’t implement it either.

The update of the created_by and updated_by model fields in many
serializers can be simplified by extracting the logic into a mixin.

We have introduced a system for custom field write permissions that
allows administrators to control which users can write specific fields
in steering.

This system is based on specific model permissions in the form of:
	{app_label}.edit__{model_name}__{field_name}

This mixin makes it easy to check said permissions simply by including
it as part of the serializer.