Add compact block filter client via Kyoto

[rustaceanrob]

Description

Adds a compact block filter backend via Kyoto. Should remain a draft PR until we have an official release for bdk_kyoto

Notes to the reviewers

I will need help writing tests, although I am not sure we need to test the node syncs, only that the node can be built and ran for a couple seconds.

Architectural notes:

Most of these decisions are a product of either kyoto or bdk_kyoto and passed through the bindings:

• Users may build a LightClient and LightNode with a namespace level function that takes node configurations.
• To start syncing, the user must run a LightNode in the background. I expose an method on the namespace level function called run_node that moves the process to a different OS thread and returns immediately
• Syncing is simple, as the LightClient simply returns a wallet Update when calling update. This can be applied directly to the wallet.
• At any time, a LightClient may broadcast a transaction
• At any time, a LightClient may shutdown the node
• A LightClient may also add more addresses (scripts) to watch with watch_address. When a user reveals a new address, it should be added to the node. Most of the time, however, the node will already be aware of the script, as bdk_kyoto peeks ahead of the last revealed index.
• The node issues a number of events and warnings, which are deferred to the NodeMessageHandler trait. The idea is the application will define arbitrary behavior, from writing to a log file to updating user interface components.

Changelog notice

• Add a compact block filter chain source

Checklists

All Submissions:

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

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

[thunderbiscuit]

Just for fun:

Binary size when including Kyoto, building the aarch64 binary on macOS using the release-smaller profile (libbdkffi.dylib): 9.7MB
Binary size without Kyoto, building the aarch64 binary on macOS using the release-smaller profile (libbdkffi.dylib): 8.6MB

Not bad at all for what is likely to be one of the most popular clients one day.

[rustaceanrob]

Awesome thank you for checking that out. Props to rust-bitcoin and tokio for keeping things tidy.