refs #177

fixes #100

fixes #235

Up until now the dashboard used a hardcoded list of rrules that matched
a long-gone fixture set of rrules in steering. Additionally, rrules were
translated in the dashboard using the the ID of the rrules in steering.
This means that any change to the fixture set, removing an rrule or not
importing the fixture set at all would mix up the translations and
therefore the actual schedules that people would create.

A few months ago the rrules were reworked and an API endpoint was
introduced that exposes the rrules defined in steering. No appropriate
change was made in the dashboard and so the rrule definitions got
out-of-sync.

This change implements a rrule store that fetches data from the API.
Additionally we’ve also implemented a custom rrule to natural language
mechanism [1]. This is because the scope of the rulesets we use in the
AURA radio context is well-known and not to complex and because rrule.js
built-in `toText` function, which might have been an option, is limited:

* bysetpos seems to be entirely unsupported
* internationalization will produce gramatically questionable
  output for languages like German, because the translation
  interface is somewhat lacking.

[1] #226 (comment 13669)

fixes #217

This increases the chance of a perfect 3 column layout.

We often find ourselves adding flex styles to buttons. Instead, this
should be the default.

fixes #199

Feedback hasn’t been to good, so we remove these again.

fixes #210

fixes #209

This refactors the existing state helpers (useCopy and
useUpdatableState) and unifies them to useUpdateBehaviour, useCopy,
useAPIObjectFieldCopy, useRelation and useRelationList. This eliminates
a lot of custom code in the show settings page and unifies the behaviour
of all input fields and save operations making the experience more
consistent and understandable.

It also enables us to show the save-in-progress state and errors that
occurred during updates for all fields along with customizable debounce
and proper v-model support.

We also got rid of the remaining uses of useSelectedShow. The show
settings page still made use of it despite using a route that
provides the relevant show that should be edited.

refs #127

refs #182

refs #191

refs #181

This refactor includes a bulk of the changes discussed in #181. It
removes the existing navbar and replaces it with a sidebar instead. This
leaves us more room for context-aware navigation options and other
information that is relevant to users.

Additionally, the show management page is now split up into two, the
show episodes management, listing the coming shows/timeslots and the
show’s schedules, and the show basic data page, that contains all mostly
static data for a show and which is usually maintained by
administrators.

refs #181

This control changes the rendering type for the show previews and should
be placed directly next to it.

This change implements a show overview page with two display modes:
table and grid. Shows can be ordered and searched. Other filters are not
(yet) implemented.

refs #101
refs #181

internal note and show owners are both admin-controlled.

refs #146

refs #155

fixes #153

refs #173

refs #151

refs #156

refs #129

refs #154

Users weren’t able to create a time slot in the calendar if the slot
has already begun.

The logic now checks if the start time is later or equal to the start of
the slot of the current time (i.e. current time is 16:37:28, check is
performed against 16:30:00 for a 15 minute calendar slot size). This
prevents users from creating slots in the past but allows them to create
time slots within a slot that has already begun.

If the slot has already begun then the start time of the new time slot
is set to the next available 5 minute slot after the current time. This
means that if the current time is 16:37:28 and one creates a time slot
in the 16:30:00 - 16:45:00 slot window the start time of the new time
slot is set to 16:40:00.

fixes #167