Disconnect blocks from `Wallet`

[rustaceanrob]

Description

In working on bdk_kyoto, we are finding that most of the functionality exists for the Wallet to just directly interoperate with the light client without much hassle. I am now just considering a couple snags that would be resolved by this PR.

Context

The light client emits potentially sparse but monotonically increasing blocks along with their height. These may be applied to Wallet with apply_block_connected_to, using the last local chain tip in the usual case.

If blocks are reorganized, the light client will emit the disconnected block header(s) along with their height(s).

Block Reorganizations

It is not intuitively clear to me how one would handle reorganizations from the Wallet API standpoint. One option is to use apply_block_connected_to with the last block that wasn't reorganized, but I struggled with reasoning through that. Within bdk_kyoto, we keep a LocalChain and apply ChangeSet to it, making the process much simpler by passing None for the height that was disconnected. I think this is a far more intuitive to use None here and apply a ChangeSet.

Allowing for this introduces a nice invariant, that one could always use the tip of the LocalChain when calling apply_block_connected_to as long as the reorg ChangeSet is applied first

Batch chain updates

insert_checkpoint is fine, however the light client will emit the 10 most recent headers when synced to the chain of most work. Inserting them as a batch via a ChangeSet offers a convenience that I suspect may also improve the RPC in the future when blocks are filtered out by CBF.

tl,dr: pls allow altering LocalChain in Wallet

Checklists

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines
• [x] I ran cargo fmt and cargo clippy before committing

New Features:

• [x] I've added tests for the new feature
• [x] 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