Move light features into their own crate

[gnunicorn]

With moving client into sc-service, we also made the light client features internal to sc-service. While this is fine for now, it means that you can't easily construct the equivalent of a light client without using the sc-service's ServiceBuilder anymore. However, only the new_light function in there is bound to client, everything else should be either in the respective crates (e.g. executor in sc-executor) or at least accessible without the need for sc-service. We should move service/client/light/{executor,backend,blockchain,fetcher} into a new crate sc-light to offer a single simple place to reuse the components.

[bkchr]

I don't understand this issue? Can you not say the same about the full node executor, backend etc code?

[gnunicorn]

Node executor, backend all other components to build a full client are indeed available outside of service, but the same isn't true for the same components if you were to build a non-service-driven light-client. And doing that (in particular to only observe grandpa finality) is what some people are doing apparently. We were not aware of this pattern before moving the light-modules into sc-service, but now they can't access them and do their super-thin-light-client anymore. The goal of this issue to expose those components again, and make them available without having to pull in the entire sc-service – same as you can pull in all components of a full-client without sc-service.