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.