Add ability to retrieve private keys as bytes

[thunderbiscuit]

This feature is needed for compatibility with LDKLite, where the initial entropy given to LDK is the private key of the root of the BIP32 derivation tree.

Closes #188

Description

Changelog notice

APIs Added:
    - Add `secret_key_bytes()` method on the `DescriptorSecretKey` [#199]

[#199](https://github.com/bitcoindevkit/bdk-ffi/pull/199)

Notes to the reviewers

I just want to make sure I understand why the BdkDescriptorSecretKey::SinglePriv(_) is unreachable (will fix the code to add the unreachable!() if my understanding is correct. Is it because we currently only build the DescriptorSecretKey from mnemonics, and always make them extendable?

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
• I've updated CHANGELOG.md

[notmandatory]

How about shortening the name to secret_bytes() same as the internal bdk function?

[thunderbiscuit]

Yeah let's do it. In this case I had made a deliberate choice because I actually don't like the API, (DescriptorSecretKey.secret_bytes? it's not explicit to me that it's about to return you the secret key). But I agree we should stick to the names we have in the Rust libs (and if I don't like it I should take it up with the upstream! haha).

Fixed.

[notmandatory]

To answer your question in the descriptor, yes, since we're only internally storing extended keys there's no chance it will be a single key. My current thinking is to add a new construction for DescriptorSecretKey somethink like .fromWIF() that would create a secret key from a WIF. I think even starting with a WIF we could still use the derive and extend functions to convert a single key to an extended key.. but I need to think that through a little more.

[notmandatory]

utACK 1b9bd6d

Up to you if you'd also like to shorten the function name to secret_bytes().