Persist fork-choice state > start from head

Currently Lodestar follow the simpler strategy (1) on start-up to just consider the latest finalized state as the head. Then sync all blocks from finalized state to head from our peers, and re-populate fork-choice graph.

Another strategy (2) is to persist the fork-choice state (on shutdown and / or periodically) and restore that state on startup. This approach will prevent "reverting" the head to a much older state. This caused:
- https://github.com/ChainSafe/lodestar/issues/3647
- https://github.com/ChainSafe/lodestar/issues/3717

**TODO**:
- [ ] Research what each other client is doing
- [ ] Estimate the positives of strategy (2) vs (1), specially in periods of long non-finality
- [ ] Estimate the complexity of strategy (2) vs (1), and the cost of persisting this data + pruning.

Only if it's clear that **positives >> complexity + cost**, consider implementing.

Start by reading the linked issues #3647 and #3717, then research how other consensus clients persist and restore fork-choice state. Compare the benefits during long non-finality with persistence, pruning, and implementation costs; the research is done when there is a clear decision on whether strategy (2) is worth implementing.

Written by the indexing model from the issue text.