Users should always be able to add new shows even if none have been
created thus far.

refs #97

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

Up until now the application was crammed in a single JavaScript file
once bundled. This forces clients to download 1.1MiB of JavaScript all
at once.

Vite uses dynamic import statements as split-points for bundles. By
using dynamic imports for our routes we can delay the loading of some
data to a later point in time when the user actually needs it. We should
still try to reduce our overall bundle size.

closes #125

closes #124

data.start wasn’t always defined so that the generated url would
sometimes contain "start=undefined".

refs #88

* basepath normalization: String.replace is not in-place.
* params: unshift adds array items, we wanted to pop the last item.

It’s nice to be able to select a week in the calendar and share it by
simply copying the URL so that another person may view the same week in
their browser.

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.

We use a script to update variables at runtime that usually can only be
injected at build time. Since we’ve migrated to Vite as build tool the
paths the string substitution has been performed on have changed.

The paths have now been updated and should be future-proof, as we take
the whole dist directory into account.

`npm install` doesn’t guarantee the installation of the dependencies
used during development. `npm ci` does.

Sometimes it’s helpful to see which dependencies are pulled in, what’s
pulling them in and what impact they have on the bundle size.
rollup-plugin-visualizer does exactly that.

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