Using :is-open="true" interferes with the dialogs close function in
nested dialogs.

Interfering with the default dialog close logic isn’t that smart because
it handles stuff like nested dialogs for us.

We need to find some other logic to close the dialog when someone clicks
on the backdrop, but that can be a task for a later time.

Using the same name as the native HTML dialog is a bad idea.

refs #89

closes #139

refs #89

We don’t want to show schedules that are in the past because they
clutter the overview.

refs #120

Schedules that only run for a single day should display when that day
is.

refs #121

closes #133

We’ve decided to move the show selector into the navbar because the
selected show is the primary state of the dashboard from which almost
all other state is derived.

Apart from that we now have support for filtering the list based on
active and inactive shows (and possible other criteria in the future) as
it was suggested in #122.

Some iteration semantics got mixed up when replacing remaining uses of
`var` variable declarations in ae37fb6c.

`var foo in bar` cannot be replaced with `const foo of bar` because the
first will assign the iteration index of the current item to foo,
whereas the second will assign the actual iteration item.

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

The show selection mechanism relied on the parent component to notify
other components, even though the selected show is already part of the
store and all component state can and should be derived from there.

This is a stopgap measure until we’ve worked on #17 [1] and added a
management interface for simple models like funding categories and show
types.

refs #97

[1] #17

Up until now we had two different show selectors based on the number of
shows that were available. We now use the same show selector for any
number of shows.

Apart from that shows are now sorted
 1. based on their active state (descending, so inactive last) and
 2. their name (ascending, so A-Z)
in the show selector so it’s easier to find relevant shows.

Other changes:
* title handling has been moved into PageHeader component
* calendar management has been removed and is now handled
  locally in the EmissionManager component
* inactive shows are badged

refs #122

Tank only returns an entries property for playlist objects if the
entries list would have at least one item. This is a bug [1].

closes #119

[1] tank#46

This was accidentally removed when migrating to fullcalendar v5 in
14a9ff20.

Accessing the $parent should only be used in rare cases. Login session
handling is already implemented as part of the store, so there is no
need to use the App component as handler.

vue-full-calendar is not the official Vue package of fullcalendar, is
only compatible with Vue 2.x, uses the outdated fullcalendar v3 library
and contains a bunch of huge dependencies like jQuery and moment.

The changes in this commit migrate the dashboard to fullcalendar v5 and
the official vue component. Apart from that there have been a few
refactors and fixes. These are:

* remove irrelevant stub event callbacks
* make view updates reactive instead of imperative
  (see removal of renderView method and introduction of renderWatcher)
* rename methods to better reflect their purpose
    resolve → enterConflictMode
    resolveEvent → resolveConflict
* emit events in modals instead of call to methods on this.$parent
* let → const where applicable to prevent accidental reassignments
* switch to for-of loops (from for-in) for better readability
* fix some typos

One other major change is that timeslot and collision data is no longer
mixed with event data for fullcalendar and is assigned to the
extendedProps property instead. As mentioned in fullcalendars
documentation on event parsing [1], any data that fullcalendar does not
handle on its own is moved into the extendedProps object with the
explicit recommendation to put them there right from the start. We
follow that recommendation.

closes #94

[1] https://fullcalendar.io/docs/event-parsing