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.

URL generation logic is complex and we should handle configuration like
basepaths and the use of trailing slashes in a central location to avoid
simple, but hard to find mistakes.

This change also gets rid of the VUE_APP_API_STEERING_SHOWS env
variable, that is just a 'shows/' suffix of the VUE_APP_API_STEERING env
variable.

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

fixes #87

Making imperative DOM API calls to apply CSS classes is
counter-productive when using a reactive frontend framework like Vue.
DOM attributes should instead be assigned based on reactive data.

fixes #117 and #118.

Notable changes:
 * Vue 2.6 to Vue 3 + compat migration.
 * Build system migration from vue-cli/webpack to Vite.
 * Application dependencies like bootstrap-vue, vue-router, vuex,
   or vue-toast-nofitication have been updated, if doing so was
   necessary or advisable for the Vue 3 migration.
 * Static file includes for the oidc-client in oidc_callback.html
   and oidc_callback_silentRenew.html have been removed in favor
   of automatic processing in the build system so that all assets
   are versioned and invalid cache hits are prevented.

Fixes #53 and #110.

moment is still needed as peer dependency but we should’t use it in our
own code anymore so we can remove it in the future.

We explicitly pass authorization for all requests and so no implicit
credentials need to be passed.

The steering API returns HTTP 400 errors for general payload and 409
errors for scheduling conflicts that we didn’t handle yet.

fixes #93

A simple b-alert list wrapper that handles the standard error format
from Django REST framework.

Views may want to display a fallback message if the translation key does
not exist.

The steering API has some deprecated attribute names that we should no
longer use. These are:

  dstart → first_date
  until → last_date
  tstart → start_time
  tend → end_time
  byweekday → by_weekday

These changes in naming have also been applied to variable names,
attribute names and translatations in the dashboard code in order to
avoid confusion.

The currently prevalent API response handling is based on a callback
pattern. This has at least two major drawbacks:

1. More broadly it facilitates the use of nested callbacks, which make
   the code harder to read and clutter stack traces.
2. Our specific callback solution does not follow the traditional node
   callback pattern that looks like `function (err, data) { ... }`.
   Instead we have `callback` and `callbackCancel`, none of which are
   meant to handle actual error/exception objects.

The latter makes it hard to write code that is executed irrespective of
the specific code path, like in a try-finally clause. In practice it’s
also a violation of the separation-of-concerns design principle as it
forces error handling to happen in the store function instead of the
caller that is best suited to handle error states.

This change attempts to facilitate a gradual migration to a
Promise-based result handling by it to co-exist with the currently used
callback pattern. Callers that don’t provide any callback functions are
assumed to handle promises whereas callers that do provide callback
functions will see no change in behaviour.

This allows us to transition one API-call at a time instead of doing one
large and time-consuming refactoring.

refs #55

* replace all `var` declarations and use `const` where appropriate
* strip unnecessary temporary variables
* replace single character variable names
* replace multiline variable declarations
* simplify expressions
* replace invalid uses of parseInt