Include onchain transactions in events

[tnull]

Closes #446.
Based on #432.

In #432 we exposed transactions in store. Here we take a stab at exposing them via events. However, to avoid emitting duplicate events for channel-related transactions, this is in draft until we have lightningdevkit/rust-lightning#3566

[tnull]

While the latest BDK 2.2 now shipped event (which would make emitting events easier on our end), we still need lightningdevkit/rust-lightning#3566 to properly classify the transactions in our store. So this remains blocked until the latter ships (likely with LDK 0.3).

[ovitrif]

While the latest BDK 2.2 now shipped event (which would make emitting events easier on our end), we still need lightningdevkit/rust-lightning#3566 to properly classify the transactions in our store. So this remains blocked until the latter ships (likely with LDK 0.3).

Is there a way we could get this into ldk-node sooner?
To be honest we (Bitkit team), kind of relied on the expectation that the BDK 2.2 PR #310 Return wallet events when applying updates will be integrated in ldk-node soon enough (ie. this month or November); and we made our roadmapping around this expectation. Now I'm getting feedback that there is no way we can delay our release any further than when it's planned, and the due date is very soon; which leaves us with very few options:

1. Get help from you to get this into ldk-node very soon (November)
2. Collaborate with you to have someone from our team help with implementation efforts (for example by fixing lightningdevkit/rust-lightning#3566), but then we will need a commitment that if we fix that, this PR takes priority and it is implemented shortly thereafter)
3. Do our own implementation for this

The team seems to lean towards favoring option 3, which is not ideal IMHO, but the main argument is that we don't really have the time to go any other route.

The issue that I see from my PoV is that option 2 might even seem faster.

Could 2 be an option?

[tnull]

Technically unblocked, but we should first land #791, as the API here will depend on the API choices there.