Revisons slider shows far fewer revisions than expected

### Expected

When viewing the revisions of a note with a lot of versions I expect the revisions slider to show quite a few revisions.

### Observed

* The revisions slider only shows a small number of revisions like 2 or 3.

For example I have a note that was created Sat Nov 29 2014 01:29:04 GMT+1100 (Australian Eastern Daylight Time) with many versions.

* The iOS app shows at least 29 revisions in the history list
* The website and in the Simplenote electron app on Linux it only shows 3: Latest, June 29, 2016, and May 17, 2015.
* The [old app](https://app.simplenote.com/old) shows what appears to be all the versions.

### Reproduced

1. Visit a note with a lot of revisions, dating back some time
2. Open the web inspector an observe the messages on the web socket
3. Click the History icon for the note
4. Observe many `e` entity request and response messages for all the versions of the note
5. Slide the revisions slider and observe far fewer versions.

* Bug observed on website version 1.16.0-2078 in Firefox 76.01
* Bug observed in Linux electron app version 1.16.0
* Bug **not** observed in iOS app version 4.18
* Bug **not** observed in old version of web app at https://app.simplenote.com/old version unknown

I've looked over the simplenote-electron code and simperium-node code but I've been unable to work out exactly why this is happening. However, most likely source of the bug to me would be the use of `setTimeout` when handing the `version` events in [collectionRevisions](https://github.com/Simperium/node-simperium/blob/986ce2a7d688dd249c346626dce76d292e01c684/src/simperium/channel.js#L862). I am located in Australia and latency from here to the US where I assume Simplenote is hosted is typically 250 to 300ms:

```
$ ping api.simperium.com
PING simperium.com (192.0.84.247) 56(84) bytes of data.
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=2 ttl=48 time=263 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=3 ttl=48 time=286 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=4 ttl=48 time=307 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=5 ttl=48 time=229 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=6 ttl=48 time=250 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=7 ttl=48 time=273 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=8 ttl=48 time=296 ms
64 bytes from 192.0.84.247 (192.0.84.247): icmp_seq=9 ttl=48 time=319 ms
```

I suspect that the [TIMEOUT](https://github.com/Simperium/node-simperium/blob/986ce2a7d688dd249c346626dce76d292e01c684/src/simperium/channel.js#L864) of 200ms is set too low for people that are far from the US. To reproduce perhaps try viewing revisions with Chrome's network throttling with additional latency added (E.g. Regular 2G):


Below are screenshots showing the messages on the websocket when clicking the History button on the website. These correspond to the request for revisions but the UI does not reflect them. You can see that most of the requested versions exist on the backend. I.e. they return an entity and not the missing entity response, `?`.


Start by tracing the History icon and revisions slider in simplenote-electron, then inspect collectionRevisions in node-simperium's src/simperium/channel.js, especially the referenced TIMEOUT and version event handling. Reproduce with added network latency and compare websocket revision responses with the versions displayed by the slider; done means available revisions are represented consistently.

Written by the indexing model from the issue text.