Add support for stateful test suites and add chain tests

[stringintech]

This PR introduces stateful test suites and adds a new suite for testing chain operations.

Key additions:

• Stateful suite support: Introduces a stateful flag for test suites where tests depend on each other's success. If any test fails in a stateful suite, all subsequent tests are automatically skipped and marked as failed. Handler processes are respawned after stateful suites to prevent state leaks between suites.
• Object reference protocol: Implements ref field and introduces registry pattern for persisting objects (contexts, blocks, etc.) across requests, enabling complex multi-step test scenarios.
• Chain operations test suite: New chain.json demonstrates stateful testing with block processing, height tracking, and chain reorganization verification. The block data used in this suite can be deterministically regenerated by this functional test.
• Method reference documentation: Restructures handler-spec.md with detailed method reference for all supported operations.
• Verbose mode: Adds -v and -vv flags to print complete request chains that can be piped directly to a handler for manual debugging and reproduction - Add verbose modes for easier handler debugging #6.

[stringintech]

Before implementing the object reference pattern with the ref field, I initially considered this approach that relied on implicit global state in the handler.

Key differences:

Old approach (implicit state):

• Chainstate manager created once, all subsequent tests assume it exists
• Empty params: {} for operations on the global state
• Multiple blocks processed in batches via arrays

{
  "id": "assert_chain_height_zero",
  "method": "btck_chain_get_height",
  "params": {},  // Assumes global chainstate exists
  "expected": {"success": true, "result": {"height": 0}}
}

New approach (explicit references):

• Each object gets a named reference (e.g., $context_ref, $chainstate_manager_ref)
• Tests explicitly pass which objects to operate on
• More granular, one operation per test

{
  "id": "chain#5",
  "method": "btck_chain_get_height",
  "params": {"chain": "$chain_ref"},  // Explicit reference
  "expected": {"result": 0}
}

The reference pattern should provide more flexibility: handlers can manage multiple concurrent contexts/chainstates, dependencies between tests are explicit, and test scenarios are more composable.

Note on option objects: I intentionally avoid exposing option objects (like btck_ContextOptions, btck_ChainstateManagerOptions) as references in the protocol. Each language binding can implement options idiomatically (builder pattern in Rust, functional options in Go, etc.) without being constrained by the test protocol. Tests pass configuration directly in params rather than creating/manipulating option objects through the protocol.

[stringintech]

Tested v0.0.3-alpha.1 locally with go-bitcoinkernel and will push a commit soon.

[stickies-v]

Concept ACK. This seems like a really elegant way to chain (hah) operations together, and wrt explicitness: I agree that the explicit approach is much better than the implicit one.

Working on other things atm but will test this out as soon as I get the chance (and having #6 addressed would make testing a lot easier).

[stringintech]

Rebased to include changes in #12 - ID no longer required in response. Also added support for the requested feature in #6.

Tested pre-release v0.0.3-alpha.2 in stringintech/go-bitcoinkernel#12 (comment).

[stringintech]

Addressed suggestion by @stickies-v in #11 (comment). Also addressed some nits and extended response validation unit tests to test scenarios where a ref object is required as result.

Tested pre-release v0.0.3-alpha.3 in stringintech/go-bitcoinkernel#12 (comment).

[stickies-v]

I think the chaining interface works really well, very nice work! I've implemented v0.0.3-alpha.3 in stickies-v/py-bitcoinkernel#42 and the interface feels very natural, I can't think of any improvements.

The verbosity flags and error message propagation have also been very helpful in implementing this, thanks.

Didn't look at the code changes or test vectors themselves, but I extensively used the handler-spec.md which made it easy to implement the interface (except for the one omission I found, as commented).

Probably won't leave any further comments on this PR, everything works nicely for me!

[stringintech]

Thanks a lot for looking into this @stickies-v and @janb84. Would merge in a couple of days if no further issues are found, to be able to add more coverage of the C API.