[marshal] Support Incomplete Epocher/Provider

[patrick-ogrady]

Related: #3126

Instead of requiring that the provider/epocher be fully populated for all heights we are processing, we should consider handling the case where we only know the latest info (if done today, we'll block peers because we can't get the epocher/provider for some height/epoch).

[clabby]

From https://github.com/commonwarexyz/monorepo/pull/3126/changes#r2818668604:

At first glance, I'm not sure changing this assumption is a good idea. Having to traverse the application state to collect epoch length state changes is sub-optimal, since moving to digest only sync is crazy slow and would stop sync on the first block that's missing (versus now, where we can fill multiple gaps starting from direct finalizations we receive.)

For teams that want to do dynamic epoch lengths that are determined by the application, a middle-ground would maybe be having the entirety of the epoch -> height range history available in the state at the tip of the chain? For more simple setups where the length is just changed by a hardfork, even more trivial, they can just hard-code in the binary.

@BrendanChou brought up an interesting alternative where we map heights -> verifier, though I think that has the same problem (you need to have a collection of height-range specific verifiers at the time of initialization, or the ability to populate them lazily without first syncing the application chain beforehand.)

If we added a variant that requires Provider::all() to be supported, this could work out nicely though.