fix: enforce Core's std tx weight limit when building transactions

[tvpeter]

Description

wallet create_tx could build transactions that are non-standard under Bitcoin Core's default policy, so they failed only at broadcast, after signing:

• Nothing limited the transaction to MAX_STANDARD_TX_WEIGHT (400,000 wu / 100,000 vB). As shown in fix transaction creation input validation and fee rate calculation #326, a 99,994 byte --add_string payload produced a 100,150 vB tx that the node rejected with tx-size.
• --add_data and --add_string documented "max 80 bytes" but was never enforced, and it stopped being Core's default in v30.

This PR rejects such transactions when they are built, with an error giving the weight and the limit. The check covers create_tx, create_dns_tx, bump_fee (where a fee bump can add inputs and push a tx over), and create_sp_tx.

It also parses --add_data/--add_string with clap value parsers, the same way as --fee_rate. That removes three copies of the same decoding block.

Fixes #339

Notes to the reviewers

• Why there is no separate datacarrier check: in Core v30, IsStandardTx checks tx-size before datacarrier, and MAX_OP_RETURN_RELAY is defined as MAX_STANDARD_TX_WEIGHT / WITNESS_SCALE_FACTOR. OP_RETURN bytes are non-witness, so at default settings any tx that passes the weight check also passes datacarrier. A separate check would be dead code.
• Accounting for witnesses (from the fix transaction creation input validation and fee rate calculation #326 discussion): create_tx, create_dns_tx and bump_fee return unsigned PSBTs. Their weight is estimated with each wallet input's max_weight_to_satisfy(), the same worst case coin selection uses. The estimate is an upper bound: a tx under it can't go over once signed. In return, a segwit tx within about 1 wu per input of the limit may be rejected. create_sp_tx signs internally, so it checks the exact weight. Inputs are looked up through spk_index() rather than get_utxo(), because a fee bump's inputs are already spent.
• Inputs the wallet doesn't own add no witness weight to the estimate.
• Testing: the unit tests sign real transactions for tr, wpkh, sh(wpkh), pkh and a fee bump, and check that the estimate bounds the signed weight tightly.
• Behaviour change: malformed --add_data base64 now exits 2 at argument parsing instead of 1, consistent with --fee_rate.

Changelog notice

• Fixed create_tx, create_dns_tx, create_sp_tx and bump_fee building transactions over Bitcoin Core's 400,000 wu (100,000 vB) standard weight limit; they are now rejected when built, counting the witnesses still to be signed

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

Bugfixes:

• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[codecov]

Codecov Report

❌ Patch coverage is 96.22642% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.42%. Comparing base (3f6b023) to head (70efe32).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/utils/common.rs	97.91%	2 Missing ⚠️
src/handlers/dns/mod.rs	66.66%	1 Missing ⚠️
src/handlers/offline.rs	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #361      +/-   ##
==========================================
+ Coverage   61.46%   62.42%   +0.95%     
==========================================
  Files          23       23              
  Lines        3989     4077      +88     
==========================================
+ Hits         2452     2545      +93     
+ Misses       1537     1532       -5     

Flag	Coverage Δ
rust	62.42% <96.22%> (+0.95%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[emma31-dev]

since you are already working on this i'll love you to address issue #360 in this same pr