Extend run_step! macro in integration_test.rs to support [SKIP] semantics

[gyorgybalazsi]

Follow-up from PR #41.

Context

The run_step! macro in examples/integration_test.rs:234-259 only handles two outcomes:

• Ok(detail) → print_ok(detail) + passed += 1
• Err(e) → print_fail(e) + cleanup + print_summary + early return

It has no [SKIP] outcome.

Three steps need skip semantics today and consequently use manual { step += 1; print_step(...); ... } blocks instead of the macro:

• Step 19: Consolidate UTXOs (skips when below consolidation threshold; pre-existing since PR feat: extend integration test with deposit, withdraw, and faucet steps #31)
• Step 20: Split sender holding (skips when sender has no holdings; introduced in PR feat: migrate JSON API calls off deprecated submit-and-wait-for-transaction-tree #41)
• Step 4: Accept free credential offer (skips when RUN_CREDENTIAL_ACCEPT is unset or no offers available; introduced in PR feat: migrate JSON API calls off deprecated submit-and-wait-for-transaction-tree #41)

Each manual block duplicates the step += 1, print_step, passed += 1, print_fail + print_summary + return Err boilerplate that the macro already handles.

GitHub Copilot raised this during PR #41 review: #41 (comment)

Proposal

Extend run_step! to accept a body returning Result<StepOutcome, String> where:

enum StepOutcome {
    Ok(String),      // calls print_ok, increments passed
    Skip(String),    // calls print_skip, increments passed (matches existing convention)
}

…or use a sibling macro like run_skippable_step! if changing the macro's body-return type is disruptive.

Then convert the three manual blocks to use the macro, eliminating ~60 lines of boilerplate.

Affected code

• examples/integration_test.rs only — no production code touched.

Out of scope

• Refactoring the // Step N: comment numbering scheme (separate concern).
• The dual-numbering convention (no-faucet vs with-faucet branch).