Refactor the JSON-RPC service code

[tomaka]

Close #786
The plan in #786 has been implemented as described.

This PR entirely removes the requests_subscriptions module, as it was over-complicated.

Rather than have one object dedicated to the entire JSON-RPC state, this PR introduces the ClientMainTask, which is specific to an individual JSON-RPC client.

The ClientMainTask is basically a state machine with two channels plugged to it: one channel that allows sending requests and responses with the task responsible for the socket (SerializedRequestsIo), and one channel where responses and subscriptions can send responses and notifications.

However, the code that the API user writes is much more simple, as evidenced by the diff.

This PR breaks the fact that unsubscription requests must match the type of the subscription. For example, you can call state_subscribeStorage to subscribe, then call author_unwatchExtrinsic to unsubscribe and it will succeed. As this is a pretty minor problem, I'm not fixing this right now, as it will be more easily fixable after some slightly further refactoring to have stronger typing for the different types of requests.

This PR also removes the max_parallel_subscription_updates config option, as it is now irrelevant. Assigning priorities to tasks is better done by adjusting the executor rather than trying to game how said executor works.