After deciding on #1079 and the preparatory steps of #1046, the light client should be fully modularized.

This is a breaking change, because unlike before, the SDK user needs to decide on what light client should be initialized, it will not be done dynamically at start up any more.

This task should introduce the following:

• SDK user can decide which light client / parentchain the worker should connect to:
  • parachain (without grandpa)
  • solochain (with grandpa)
  • Both solochain and parachain light clients
  • None does not need to be an option for now, as all known worker use-cases, even the teeracle, need to talk to a parentchain. If needed in the future, a different ParentchainHandler could be introduced that only contains an extrinsic sender for the teeracle. But as long as the sync call is not called, there is not much overhead.
• Just like the light client init, the parentchain syncing needs to be adapted. The block fetching side (e.g. the ParentchainHandler on the untrusted side) should be able to decide to which parentchain the block belong to. That should happen via the parentchain_type param that is passed into the enclave via e-call.
• The worker will sync the blocks accordingly.