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