Change underlying sink write(chunk, done, error) to promise-returning write(chunk)

This is a change for stream creators only, and not for stream consumers. It is motivated by fixing #135.

Now that we have benchmarks, we can try things like this.

This fixes #135 since the calls to [[onWrite]] are no longer recursive, but instead put onto the microtask queue.

There is a semantic change: if the underlying sink is able to acknowledge writes synchronously, that will *not* help the stream transition back to writable.

Benchmarks show no real difference (i.e., the variation between two runs of the async version is similar to the variation between the async and sync versions). Raw results, with filenames replaced with descriptive names (I ran both sync and async benchmarks twice):

```
async #2 (current) vs. sync #1 (current - 3)
-----------------------------------------------------------------------------
16,1024,15,0,sync,0.3,0,0,0,sync      -64.807857  0
16,1024,15,4096,sync,0.3,0,0,4096,15  -16.913984  +1
16,1024,5,4096,0,0.3,0,0,4096,15      -0.885328   +2


async #2 (current) vs. sync #2 (current - 2)
-----------------------------------------------------------------------------
16,1024,15,0,sync,0.3,0,0,0,sync  -64.891073  0
16,1024,5,4096,0,2,0,0,0,sync     -2.998018   -2
16,1024,5,4096,0,0.3,0,0,4096,15  +1.055062   +2
1,1024,sync,0,5,2,0,0,4096,15     -16.960175  0


async #2 (current) vs. async #1 (current - 1)
-----------------------------------------------------------------------------
16,1024,15,0,sync,0.3,0,0,0,sync  -61.959043  0
16,1024,5,4096,sync,2,0,0,0,15    +15.920144  0
16,1024,15,4096,sync,2,0,0,0,15   +16.867793  0
16,1024,0,0,sync,0.3,0,0,4096,15  +17.050724  0
16,1024,5,4096,0,0.3,0,0,4096,15  +0.992007   +2
```

Here negative numbers are generally good. (I should make the benchmark tell you that...)

I think you are right that we can simplify this, perhaps even by only using `[[state]]`. I will try updating to that approach and write any tests necessary (or maybe the ones we have already are enough).