Select contracts implementing the correct trait from the Clarinet project for argument generation

[BowTiedRadone]

This PR adds support for arbitrary selection of trait reference parameters. The new logic for handling trait implementations in trait reference parameters is as follows:

• If a trait reference parameter is found in public functions or invariants during invariant testing, or in test functions during property testing, Rendezvous will scan the user's Clarinet project for a contract that implements the referenced trait.
• If trait implementations are found for that specific trait reference, they will be added to a selection pool. Rendezvous uses fast-check to randomly select one of them for each run, ensuring seed-based randomness.

To test contracts with trait reference parameters, users must select at least one trait implementation for the referenced trait and add it to their Clarinet project, either as a direct contract or a project requirement.

This PR resolves #65.

[moodmosaic]

Interesting work on the draft implementation so far! Left some comments.

The next steps I see are:

• Create (perhaps parameterized?) test(s) based on the draft/example in property.ts.
• Add as many more test cases as possible to expand coverage.
• Tweak the draft implementation to ensure all tests pass.
• (Once tests provide decent coverage, we'll consider refactoring with a
  parsec-style library.)

[moodmosaic]

Left questions and comments at the abstraction level. Let's make sure we get those right before proceeding.

[moodmosaic]

This is massive 🥇 After refactoring simnet and coming up with candidate alternatives for "enrich" this should be ready for review.

[BowTiedRadone]

Gigantic cleaning session happened here. At least a couple things to decide on before merging:

• Which contract that imports traits should be added to the example folder? It could be a handmade contract, but it should showcase the functionality clearly.
• Which contract that implements traits do we want to use? This can either be a handmade contract added to the project or specified as a requirement.

Ideally, we should have two trait implementations for the same trait, so Rendezvous can randomly pick one of them for any trait reference parameter.

[moodmosaic]

Which contract that imports traits should be added to the example folder? It could be a handmade contract, but it should showcase the functionality clearly.

Any contract that shows a real-world use case and stays under 100 lines.

Which contract that implements traits do we want to use? This can either be a handmade contract added to the project or specified as a requirement.

I'd say both: a local handmade one and one added as a requirement.

[moodmosaic]

This is a massive and tricky-to-implement PR. It's been carefully crafted, and I want to leave an approval noting that it's one of the most well-crafted PRs (of this size) I've reviewed in over a decade.

I've left a few comments, but they aren't blockers. It would be nice to address them, but we could merge and handle those separately if needed.

One thing to consider for this PR is whether to keep the full commit history or squash it into a single commit. Keeping the history preserves individual commit context, which can be helpful for debugging and provides a detailed timeline of changes. On the other hand, it can make the history noisier with too many intermediate commits.

Squashing into a single commit results in a cleaner, more concise history, making it easier to track high-level changes. It also simplifies git revert if we need to roll back due to blockers, which is especially useful since we're still < v1 and can afford breaking changes. However, squashing does lose the detailed commit trail, which can sometimes be useful for debugging.

As Linus Torvalds put it: "I want clean history, but that really means (a) clean and (b) history." (Source: https://www.mail-archive.com/[email protected]/msg39091.html)

[moodmosaic]

#88 (review)