Speed considerations of ffi

I noticed that BDK ffi is slow. E.g. the `peek_address` takes 0.2ms which quickly adds up to the range of seconds.

Similar with crucial functions like `__str__` .

I assume the actual bdk code is fast, which leaves the ffi interface. The apparent overhead seem to be the ffi wrappers:

I am not sure how to circumvent this. One idea is that one could try to batch operations. Instead of `peek_address` 3000 times, one could give a range or list of indices and get a batch back. It is however not certain that this would help. It probably depends on how often these ffi wrapping functions are called.

### batching test
Using https://github.com/andreasgriffin/bdk-ffi/tree/add_peek_address_batched which adds `peek_address_batched` with
[benchmark.py](https://github.com/user-attachments/files/22991609/benchmark.py) the results are
```
Sequential peek_address duration: 0.131605s
Batched peek_address_batched duration: 0.100451s
```
which hints, that simple batching is not sufficient for a speed improvement.

### links
https://mozilla.github.io/uniffi-rs/latest/internals/lifting_and_lowering.html

tagging: @thunderbiscuit

Start by running the linked benchmark.py against sequential and batched peek_address calls, then read the linked UniFFI lifting and lowering documentation. The issue names no implementation files or acceptance threshold; a contribution would first need an agreed bottleneck and measurable performance target.

Written by the indexing model from the issue text.