Reimplementation required due to rusty-kaspa visibility constraints

[smartgoo]

This project is built from bindings to rusty-kaspa source. As such, an obstacle we frequently run into is the ability to access rusty-kaspa source outside of rusty-kaspa crates.

In a best case scenario, the rusty-kaspa source needed is pub. We can then wrap that rusty-kaspa source and leverage native RK logic.

When rusty-kaspa source is private, it requires reimplementation (to some degree) in this repository.

The following is a work-in-progress list of private rusty-kaspa source that this project has ran into:

rusty-kaspa object	Impact
struct Keypair	Reimplementation for PyKeypair
struct PrivateKeyGenerator	Reimplementation for PyPrivateKeyGenerator
struct XPrv	Reimplementation for PyXPrv
struct PrivateKeyGenerator	Reimplementation for PyPrivateKeyGenerator
pending field of struct Context	alternative approach used for PyUtxoContext::pending() and PyUtxoContext::clear()

At some point we should have a conversation with RK core on best path forward. Ideally these could be exposed via some means - pub, exposed methods, etc. Even if gated behind a new feature flag e.g. bindings or public-api. It may also prove beneficial to future bindings efforts (for other languages), rust developers, etc. for these to be available.