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...)

IIUC, we remembered the promise than using a boolean flag so that we can ignore extra `signalDone()` calls once we move onto processing the next write. While we're processing the next write, `[[currentWritePromise]]` is not **undefined** but pointing to the promise for the next write. We had to determine if the write corresponding to the signalDone() is still ongoing or not by comparing the promise instances (`[[currentWritePromise]]` and `writeRecord.[[promise]]`).

Now, we're switching to use Promises than `signalDone()`.

- We start processing the next write only after the promise for the current write is resolved.
- The promise can be resolved only once.

So, can't we replace `[[currentWritePromise]]` with a boolean, say, [[hasPendingWrite]] and look at it and `[[state]]`?