Cannot build nanoq correctly purely as a library on top of current std promises

[erights]

Attn @kriskowal @dtribble, @warner, @tvcutsem, @kpreid, @FUDCo

The original Q builds both std promises and Q's functionality on top of non-promise (or pre-promise) std JS. This was of course originally necessary since Q precedes and inspired std promises. The initial premise for nanoq is that the core functionality of Q (or, at least the core subset needed for Dr. SES) can be built as a shim on top of std promises, enhancing the functionality of those promises in place.

The experiment got far enough to identify problems that falsify this premise. The clearest is that there's no way for a shim to hook promise forwarding, where unsettled promise p gets forwarded to unsettled promise q. However, if p represents a local unsettled promise, q is a local unsettled promise representing a remote unsettled promise, we first eventual-send messages into p, and then we forward p to q, nanoq would need to requeue those messages onto q, so that they can be sent remotely. However, there's no way for nanoq to arrange to get the notification it would need to do this.

Alternatively, I suggest the following more modest goal for nanoq:

We rebuild nanoq in two layers.

Layer1 starts with a fully conforming minimal clean implementation of std promises in JS that does not use platform promises, and (at first) enables nothing beyond the std. We completely replacing platform promises with this shim, verifying that all tests pass. There may be some tests we cannot make pass, if there are some interactions with other parts of the JS spec that use platform promises. We identify these issues and make these mismatches as inconsequential as we can.

Layer2 starts as the nanoq we've got, layered on top of Layer1 as if it were platform promises. Then, we proceed to fix nanoq into the core Q behavior needed for Dr. SES, enhancing Layer1 with additional hooks as needed for this purpose.

Having identified a minimal set of adequate additional hooks we need to add to Layer1, we then craft that into a tc39 proposal.

We avoid getting stuck. Until those hooks get accepted into std JS and shipped, we continue to replace std promises and operate as above. Once they do, we can swap out our Layer1 and run the Layer2 nanoq directly on top of std promises as we'd originally hoped to.