Fix rpc message order

[turuslan]

Looks like original code expected subscription events to arrive earlier than subscription id, e.g.:

{subscription: 1, result: ...}
{subscription: 1}
{subscription: 1, result: ...}

But there were two problems:

1. removing processed messages was skipping some messages
2. always reading before checking queued messages delayed those messages processing

[arjanz]

Thanks for the PR, I will have to run some tests to be sure that there are no unwanted side effects.

As you can imagine it was a bit of a struggle to make the async behavior of the websocket RPC play nice in a sync environment. Changes I already made where the introduction of the message queue and a13577e to fix race conditions between the subscription id and the first event of that subscription id.

There were sometimes still unexpected results though, so I'm looking forward to review this change, hoping to fix those issues.