This way we can use the existing server error handling infrastructure
from the newer fetch-based API implementations.

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

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.

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