Adapter.relax chaining

[dhilt]

For issue #220.

1. Internal "relax" promise chain

The Adapter.relax method becomes chainable: running a random sequence of N "relax" methods will result in a chain of N promises running strictly one after the other.

Imagine we have 2 async processes that are sensitive to the Scroller's internal processes, and both want the Scroller to be relaxed before running the logic:

async runProcessA() {
  await this.datasource.adapter.relax();
  ...
}
async runProcessB() {
  await this.datasource.adapter.relax();
  ...
}

Prior to this PR, there was possible to fall into a race condition between A and B, for example if both methods were called during the same UIScroll Workflow cycle, or even during the same javascript call stack. This PR handles such situation and provides an additional internal queue for any number of logical units (...) that are protected by the "Adapter.relax" promises.

2. Return value of "relax"

As we know, each Adapter method returns a promise of

{
    success: boolean,
    immediate: boolean,
    details?: string
}

This PR makes it true also for the Adapter.relax method, and there is one important case where it might be very useful. Imagine the following sequence running in the same call stack:

runProcessA()
Adapter.reload()
runProcessB()

Reload is not protected by "relax", we just want to interrupt the Scroller and stop all its activities. Scroller can't cancel the code following after the Adapter.relax promise, but it can tell that the flow was interrupted, it uses "success" field:

async runProcessB() {
  const { success } = await this.datasource.adapter.relax();
  if (!success) {
    return; // we don't want to proceed if the Scroller has been reloaded
  }
  ...
}

So, if the App can reload the Scroller, I would suggest to use the Adapter-relax-success protection.