API object attribute names are now:

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

refs #127

refs #89

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

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

refs #88

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.

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.

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

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

when updating only single items we should not set the
show loading info to true. otherwhise the whole ShowManager
sub components will be reloaded. also it is not true
that the show is loading.

if we want to indicate an ongoing update of the show, we should
introduce a specific flag for that.