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)

The playout expands unknown-length entries to the remaining time of the
timeslot if there is only one unknown-length entry.

refs #127

refs #127

refs #127

fixes #209

refs #127

refs #127

refs #191

refs #181

refs #127

refs #127

refs #127

This should make the API functions more accessible for callers as there
won’t be any loose undefined values that were sometimes needed to skip
certain values in certain API endpoints.

Instead, every positional argument is now required and all configurable
options or extensions are part of the options object.

Using the ID type makes type errors more likely because we accept a
wider range of types as arguments for API operations than we actually
support on a logic level, i.e. when using maps because

	Map<ID, T>.get('1') !== Map<ID,T>.get(1)

refs #185

refs #146

refs #127

refs #127

API object attribute names are now:

1. camelCased (#164)
2. use Id / Ids suffix for object references (#172)

refs #127

closes #138

Not all API endpoints will have the same behaviour. Some may only allow
updates but can’t remove items, others will use a paginated result list
instead of a plain result array.

This re-implements the auth store with pinia.

Other notable changes:
* the OIDC client configuration and setup is now part of
  separate module that can be included by the OIDC callback routes
  and ensures that we always use the same OIDC client configuration.
* Authorization headers for the steering and tank REST APIs are now
  set with an axios interceptor instead of specifying them for each
  API store action.

refs #127