Refactor Settings and SyncManager

[piotrm50]

We should re-think Settings and the SyncManager altogether imo.
Currently, Settings is a weird mix of the state of an engine and its configuration. This becomes quite clear when looking at its Export method. Where we only export

• latest commitment
• latest finalized slot (is this even good? as it might lead to different snapshots (when comparing directly or just hashes) as it incorporates a subjective measure. maybe it should be the finalized slot at the export slot or something)
• protocol versions
• future protocol parameters
• protocol parameters

All the rest is more of a state.

As for the SyncManager this is more like a state of the engine. In a future PR we should probably move all state related properties to the SyncManager, maybe consider renaming it and implement a reactive wrapper around kvstore.TypedValue for convenience access and subscription to changes.

Originally posted by @jonastheis in #680 (review)