feat(wallet): add TxBuilder::replace_tx

[ValuedMammal]

This PR adds a new method TxBuilder::replace_tx that offers a simple way of creating replacements without relying on the mechanics of build_fee_bump. See #1374 for context and motivating discussion.

In summary, there are a few limitations with the current build_fee_bump:

1. It doesn't prevent the wallet from accidentally selecting the outputs of the replaced tx as inputs to the replacement
2. The UX is somewhat rigid because it assumes all of the same inputs and outputs should appear in the replacement. (however despite this second point we somehow neglect to reuse the original drain script?)

In contrast replace_tx is useful when we only need to create a conflict and flexible enough to further tweak the parameters as desired.

Notes to the reviewers

• TxBuilder::add_utxos is modified to look for potentially spent outputs, provided that the builder is in a bump-fee context.

Changelog notice

• Added method TxBuilder::replace_tx
• Added method TxBuilder::previous_fee

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

[evanlinjin]

Should we still allow replacement if we can't determine the previous tx's fee/feerate?

[evanlinjin]

ConceptACK, ApproachACK.

Just need to make sure we don't use descendant outputs from tx we are trying to replace.

It's out of the scope of this PR, the inability to set both feerate/fee amount constraints together really bothers me. We should probably switch to the bdk_coin_select crate soon.

[evanlinjin]

Should probably warn that we don't help keep the original tx's recipient.

[ValuedMammal]

I made a few small changes including a test for unspendable descendants. I'm still open to discussing the right UX for replace_tx.

[notmandatory]

Since still some open ux design questions I removed this from the 1.1 milestone.