feat: Limit initial scan to last N blocks

[rustaceanrob]

"Closes" #603, although additional features similar to this one may be useful in the future, so I will leave that issue open.

This introduces a method on the builder so users can take a fixed N amount of filters from the tip, after they do headers sync. This should significantly speed up the startup time for new users that just want to interact with their wallet straight away.

[thunderbiscuit]

I don't feel like I'm knowledgable about the codebase enough to give a full ACK for this, but I do wanted to comment with 2 things:

1. I've been focused on trying to build an intuitive and flexible API for end users of compact block filters in production, and so that comes through the bdk_kyoto crate (for me at least). If this low-level change allows positive changes on that API, I'm all for it! But if I may, I'd suggest that it'd be great to see how it comes through for the end users on the bdk_kyoto crate before merging this (unless this PR is considered a strict improvement that can happen regardless of what bdk_kyoto does with it). A PR that would explore the separation between the checkpoint slash trusted block headers and the download of CBFs would be great, since this IMO needs more clarity and flexibility than the ScanType currently allows for/expresses.
2. When looking at the API, I was wondering what exactly happens if some of the configurations are not consistent with each other. It's a corner case but still; if a user provides a checkpoint that was merged an hour ago but sets Builder::scan_filters_from_tip(100_000), it feels like a footgun since the behaviour there is underfined in my mental model of what the builder will do.

[rustaceanrob]

I'd suggest that it'd be great to see how it comes through for the end users on the bdk_kyoto crate

I drafted bitcoindevkit/bdk-kyoto#165 which introduces a new type to enforce some of these constraints. There are three routes to start a sync, each one conveying what they are intended for. The builder is then constrained by switch route the user chooses. For instance, if a new wallet is the intention, the configuration introduced here is set under the hood. Other routes do not interact with this at all.

[rustaceanrob]

#606 is preferred IMO