Add relative timelock enforcement functions

[schoen]

Add timelocks.simf with relative timelock enforcement functions enforce_relative_distance and enforce_relative_duration. These are direct replacements for the deprecated jets jet::check_lock_distance and jet::check_lock_duration. You can learn more about how to use these at https://docs.simplicity-lang.org/documentation/timelocks (which currently includes a more verbose version of these same functions, which I plan to trim from there once they're part of the standard library!).

I wrote these functions based on conversations with @apoelstra and @roconnor-blockstream about how these jets were supposed to work, and I've also tested enforce_relative_duration a bit in contracts.

There are 11 Simplex test cases created by Claude. I asked Claude for each individual test case, and I'm satisfied that they test most of the most important cases and that they work properly. The remaining gap is that Simplex currently can't simulate the passage of realtime effectively (see BlockstreamResearch/smplx#126), so we lack tests for the happy path of enforce_relative_duration, and for its failure cases where sufficient realtime has actually passed but is not correctly asserted in the transaction.

Since Simplex can ask elementsd to simulate mining blocks, we have valid tests for Distance cases (enforcing that a certain number of blocks have been mined on top of the original transaction containing the input UTXO). This is handled via blocks_to_mine in the run_with_sequence function added to tests/common/core.rs.

Claude also wrote comments about what the various tests and helper functions do. These comments certainly do read like they were written by an AI and may be unnecessarily verbose about Claude's reasoning about the internals. I'm happy to trim these comments or rewrite them if they seem too verbose to anyone.

It's possible that tx_version_below_2_fails isn't a very good test because it may just be shoehorning a version 1 into a transaction that is not otherwise valid as a version 1 transaction, and then confirming that it gets rejected (so it could be more realistic to try to construct a valid version 1 transaction here, in order to ensure that the transaction isn't rejected for the wrong reason).