Run All implementation does not account for COM channel communication that may be dependencies of cells below

The [code](https://github.com/jupyter/notebook/blob/166b709a6aa1b5c27b713c5789f10b7d24de5d18/notebook/static/notebook/js/notebook.js#L2030) below is what used for `Run All Cells`.

``` javascript
Notebook.prototype.execute_cells = function (indices) {
if (indices.length === 0) {
return;
}

var cell;
for (var i = 0; i < indices.length; i++) {
cell = this.get_cell(indices[i]);
cell.execute();
}

this.select(indices[indices.length - 1]);
this.command_mode();
this.set_dirty(true);
};
```

The basic `for loop` ends up generating a queue of `execute_requests` calls. The problem that I'm seeing with this code is that it does not give the responses from cell execution the opportunity to inject additional `execute_request`s in the queue prior to the following cells. On the contrary, these new `execute_request`s are appended to the queue behind the other cells in the document.

An example of `execute_request`s that might need to be injected into the queue at appropriate locations would be COMM channel communication that might be needed to bootstrap a widget before the following cell might make use of it.

This problem is exposed in dashboards with declarativewidgets ([this issue](https://github.com/jupyter-incubator/declarativewidgets/issues/25) provides some details), but there might be other cases (i.e. ipywidgets).

A potential solution might be to rather than using a `for` loop, cell execution is done in a chain of promises. If all `kernel.send()` messages are done sync (at least queued sync), then we might have a chance perform COMM channel communication before the next cell gets a chance to execute.

Note that this COMM channel does not necessarily need to be initiated browser side. The code in the cell might actually have Python code that does some COMM chatter. Without a fix, any additional COMM sent from browser would be appended to the end of the queue and might be too late.

/cc @parente @jdfreder @SylvainCorlay

Start in notebook/static/notebook/js/notebook.js at Notebook.prototype.execute_cells, then trace how cell.execute() queues kernel messages and how COMM responses are handled. Reproduce the Run All ordering problem with dependent cells or widgets. Done means communication-triggered execution requests can be processed before later dependent cells rather than being appended behind the entire document queue.

Written by the indexing model from the issue text.