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.

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.

when the app is mounted we cannot log to the vue logger yet
this throws an error before the signOut method is called

now fixed by using console.log only in debug environments

vue always throws a render error, even if we include a test for user.steeringUser
before comparing user.steeringUser.is_superuser.

so we moved it to the js logic and use a separat modules array for superusers

* deactivate superuser entries for standard users
* consistent naming

New linter rules:
* curly
* block-spacing
* keyword-spacing

Also apply all autofixes introduced by these rules

Our linting config in package.json was:
```
    "extends": [
      "plugin:vue/essential",
      "eslint:recommended"
    ],
```

Now switching to "plugin:vue/recommended" and apply all auto-fixes

New following a different approach to static assets.

See https://www.jerriepelser.com/blog/using-auth0-with-vue-oidc-client-js/
for how to use OIDC client with the npm sources and per-compile updating
the static asset.

Also environment variables now work a bit differently.

Updated README.md accordingly

Superusers should see all shows. Ordinary users only those shows that belong to them.
Therefore we have to fetch the user data from the steering backend as well (OIDC info
alone does suffice here).

We need this info later too, when we implement user managament and profile settings.

In the ShowManager we now generate the GET URI depending on the superuser status.