feat!(chain): implement CheckPointEntry WIP

[LagginTimes]

Description

This PR builds on #1582 and introduces a new CheckPointEntry type to represent checkpoints in a more structured way. It captures both the block data and optional backreferences, enabling chains to be merged even without an explicit point of agreement.

WIP

Notes to the reviewers

Changelog notice

Checklists

All Submissions:

• I followed the contribution guidelines

New Features:

• I've added tests for the new feature
• I've added docs for the new feature

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[evanlinjin]

I was talking to @LLFourn about this and he suggested an alternative approach.

Instead of introducing a new concept (CheckPointEntry), we can make the checkpoint's data field optional (since not introducing a new concept is simpler).

This means we can push empty CheckPoints on a chain, and pushing a non-empty CheckPoint may push an empty CheckPoint before it (to take the prev_blockhash into account).

The downside of this is we are introducing an invariant to CheckPoint (it may or may not have the data). However, with the CheckPointEntry approach, we are already doing the same when iterating through CheckPoints. Would this invariant directly on CheckPoint be troublesome?

[LagginTimes]

Replaced with #2024.