Sync to specific block

**Describe the enhancement**
Currently, there is no way to sync a [`Wallet`](https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.Wallet.html) to a specific block (and no further).
One can [specify an initial chain tip in a sync request](https://docs.rs/bdk_core/0.4.1/bdk_core/spk_client/struct.SyncRequestBuilder.html#method.chain_tip), but there is no way to specify a _target_ chain tip. A sync always ends with the current best tip.
There is no way to disconnect a wallet tip either, so syncing to current best tip and then disconnecting blocks is not possible (#1271, bitcoindevkit/bdk#1655).

It should be possible to either:
* Disconnect blocks from a [`Wallet`](https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.Wallet.html)
* Specify a target chain tip in a [sync request](https://docs.rs/bdk_core/0.4.1/bdk_core/spk_client/struct.SyncRequestBuilder.html#method.chain_tip)

**Use case**
In an application that needs to keep a wallet in sync with some other component that updates on each new tip (eg. a mempool), an initial sync process is quite awkward:
1. Load wallet
2. [Subscribe to `sequence`/`rawblock`/`hashblock`](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md)
3. Sync wallet
4. Sync other component to wallet tip
5. Persist wallet
6. Ignore tip updates older than wallet tip
7. For each new tip, [apply block](https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.Wallet.html#method.apply_block) to wallet and other component, and persist wallet

In particular, the requirement to sync a wallet to the current tip before anything else is a constraint on application architecture - it is more complex to perform initial sync concurrently, since a wallet may sync to a different tip than another component. If that other component also does not support disconnecting blocks, one needs to repeatedly attempt to sync each to the same block.

If specifying a target chain tip for sync was possible, an initial sync process could look like
1. Load wallet
2. [Subscribe to `sequence`/`rawblock`/`hashblock`](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md)
3. Get current best tip
4. Sync & persist wallet, sync other component to best tip
5. Ignore tip updates older than wallet tip
6. For each new tip, [apply block](https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.Wallet.html#method.apply_block) to wallet and other component, and persist wallet

If disconnecting blocks was possible, an initial sync process could look like
1. Load wallet
2. [Subscribe to `sequence`/`rawblock`/`hashblock`](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md)
3. Get current best tip
4. Sync wallet, sync other component to best tip
4. If wallet tip is behind best tip, connect blocks; If wallet tip is ahead, disconnect blocks
5. Persist wallet
6. Ignore tip updates older than shared tip
7. For each new tip, [apply block](https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.Wallet.html#method.apply_block) to wallet and other component, and persist wallet

Start with Wallet, SyncRequestBuilder::chain_tip, and Wallet::apply_block in the linked API documentation, then compare the two proposed approaches: disconnecting blocks or adding a target chain tip. Review the described ZMQ synchronization flow and determine which API behavior best supports keeping wallet and other components at a shared tip. Done means the selected approach is clearly specified and supports the stated initial-sync use case.

Written by the indexing model from the issue text.