go: Storage committee worker should be responsible for both runtime light history and state

As pointed out in the mini design doc, go/worker/storage/committee should be responsible for both updating and pruning of both runtime state and light history.

As such, this worker should also provide a synchronized view of the two databases to any client that requires it. This would also resolve the current issue of history.History containing synchronization logic it shouldn’t be responsible for.

Currently, storage committee worker is only started in case of the local storage (see). However, even without the runtime state, you may still have light history locally, and there is nothing stateless about it.

Instead this worker should handle two levels of local storage/state:

1. Light storage only (runtime history).
2. Full storage in combination with 1.
   • Significantly overlaps with #6307.

In the future this enables us to:

1. Create seperate p2p protocol for runtime light headers, so that stateless clients do not reindex history (using stateless client backend - slow), but instead fetches it from the p2p network.
2. Implement different pruning strategies for consensus/runtime light/full state.

Start with the linked mini design doc, go/worker/storage/worker.go, and the storage committee worker and history.History it references. Compare the scope with #6307; done means the worker owns updating and pruning light history and runtime state, provides their synchronized view, and is started for light storage as well as full storage.