Preparing light client structure

[svyatonik]

Mostly extracting some traits + moving code around. Main changes are:

• single Service implementation remains. In Parity there are two separate services, so I'm not sure this'll work, but for now it looks it will;
• two Clients implementations (full and light). Extracted some traits from current full client implementation, to (probably) implement in light client (StateData, ChainData, ContractCaller);
• single RPC to work with for both full && light clients;
• updated network service to ease adding of light protocol;
• extracted some parts of code into separate files, where it seems appropriate.

There are now stubs for both light client + light protocol implementations.

[arkpar]

Do we really need a separate network protocol for the light client? My idea was to have a common protocol. In fact I believe that current protocol has almost everything needed for the light client sync.

[arkpar]

Same question goes for the client. Could the light client be just another backend to existing client implementation?

[svyatonik]

Well, maybe I came out with this PR too early - still researching :) I'm also not 100% sure if this separation is required, but looks like (it is possible that I'm just missing it):

1. current protocol lacks something required light client (proofs);
2. current protocol + sync is built for full chain download. But I guess this can be addressed by adding alternative implementation of substrate/network/src/sync.rs && slightly altering the protocol.rs, instead of adding separate 2nd protocol.

I'll close this for now && will research if reusing Backend and Protocol is possible. Thanks!