Reject out-of-range OP_PICK and OP_ROLL indices without panicking

[adrienlacombe]

OP_PICK and OP_ROLL count the selector itself when checking the accessible stack size. With a one-element pool and selector 1, the guard passes and the subsequent top(...).unwrap() panics. A zero selector with no pool also panics. Require both operands and exclude the selector from the pool length so these inputs return ExecError::InvalidStackOperation.

The six regression tests exercise both opcodes in Legacy, SegWit v0, and tapscript contexts: first/last valid indices, a one-element pool, exact and larger out-of-range indices, negative indices, missing operands, and preserved numeric-encoding errors. Default execution options and successful stack transformations remain unchanged.

Bitcoin Core v30.3 checks the same two-operand minimum and bounds the index against the stack after removing the selector (pinned source, 49faec4f87f5cd19c88db01a82e5c68b087c8227). An independent complete-Taproot regtest comparison with that release rejected exact-pool OP_PICK/OP_ROLL cases through block validation with “Operation not valid with the current stack size”; this executor panicked on the same script and data inputs before this fix.

Validation:

• Against unchanged ba96bc2, two of the six new tests fail with the reproduced panics.
• After the fix, cargo test --locked --all-features -- --skip fields:: passes: 11 existing unit tests, 6 regression tests, and 1 doctest.
• The new test file is rustfmt-formatted; git diff --check passes. Tests use a locally generated, ignored Cargo.lock.

Related: #18. This patch is based directly on ba96bc2 and does not depend on that resource-limit fix.