Ensure `CheckPoint` chain methods validate and link via previous blockhash

[evanlinjin]

Describe the enhancement

#1582 made CheckPoints generic so that we can attach Headers and Blocks to a given CheckPoint. Since these newly supported data types have prev-blockhashes, this introduced a new invariant: prev-blockhash of the current checkpoint must match the (current_checkpoint_height-1)'s checkpoint's blockhash (if it exists).

Additionally, when merging chains with prev-blockhash data means even if two chain do not have a point-of-agreement, they may be able to connect if a chain's prev-blockhash matches a checkpoint in the other chain.

Proposed Changes:

• Extend ToBlockHash to have knowledge of whether the data contains a prev_blockhash.

  pub trait ToBlockHash {
      /* Other method */
    
      fn prev_blockhash(&self) -> Option<BlockHash>;
  }

• Modify CheckPoint to support having empty data. When a checkpoint with a prev-blockhash is inserted, also insert an empty-data checkpoint at height-1.

Use case

Ensures consistent representation of data.

Impact

We catch problems earlier. Either as the chain-source when they construct the CheckPoint update, or when trying to apply the update to the receiving structures afterwards.

Are you using BDK in a production project?

• Yes
• No
• Not yet, but planning to

Which backend(s) are relevant (if any)?

Yes, this will affect all chain-source implementations that construct checkpoint updates. This will also affect applying updates as the problem might be caught there.

Project or organization (optional)

I get funded by the BDKF and I also work for Frostsnap.

Additional context

Original comment: #1582 (comment)

[ShivamS-D]

Can you assign this issue to me..

[LagginTimes]

Can you assign this issue to me..

Thanks for offering to help! This issue is already assigned and being addressed in #2024. Any help reviewing or testing that PR would be very welcome!